Week 07 · 2과목 네트워크 보안

미리 외워둘 숫자 (2과목 전체 공통)

Day 1 · DoS / DDoS

1-1. 개념: 가용성(Availability)을 노리는 공격

DoS(Denial of Service, 서비스 거부) 는 정보를 훔치거나 바꾸는 것이 아니라 서비스를 못 쓰게 만드는 것이 목적이다. CIA 중 A(가용성) 를 공격한다. 시스템의 유한한 자원 — ① 네트워크 대역폭, ② 서버의 연결 테이블·메모리·CPU, ③ 애플리케이션의 스레드·세션 — 중 하나를 고갈시키거나, ④ 프로토콜 구현 버그를 건드려 시스템을 멈추게 한다.

• DoS: 공격자 1대 → 피해자. 출발지가 하나라 차단이 쉽다.
• DDoS(Distributed DoS): 악성코드에 감염된 수천~수만 대의 좀비(봇) 가 동시에 공격. 출발지가 분산되어 IP 차단만으로는 막기 어렵다.
• DRDoS(Distributed Reflection DoS): 공격자가 출발지 IP를 피해자 IP로 위조해 정상 서버(반사체, Reflector)에 요청을 보낸다. 반사체는 아무 죄 없이 피해자에게 응답을 쏟아낸다. 응답이 요청보다 크면 증폭(Amplification) 까지 일어난다.

1-2. 공격 분류 (어떤 자원을 고갈시키나)

대역폭 소진형은 회선이 먼저 막히므로 서버 앞 장비로는 못 막는다 → ISP·클린존·CDN 같은 상위 단에서 막아야 한다. 애플리케이션형은 트래픽이 적어 정상처럼 보이므로 임계치·행위 분석이 필요하다.

1-3. SYN Flooding ★★★

원리 (단계별)

1. 공격자가 서버의 열린 포트(예: 80)로 SYN만 대량 전송한다. 출발지 IP는 보통 존재하지 않는 IP로 위조한다.
2. 서버는 정상 절차대로 SYN+ACK를 보내고, 연결 정보를 백로그 큐(Backlog Queue, half-open 연결 대기열) 에 넣은 뒤 SYN_RECV 상태로 ACK를 기다린다.
3. 위조된 IP는 실제로 없거나 SYN을 보낸 적이 없으므로 마지막 ACK가 오지 않는다. 서버는 SYN+ACK를 몇 번 재전송하며 타임아웃(리눅스 기본 약 1분대)까지 기다린다.
4. 그 사이 백로그 큐가 꽉 차면 새로운 정상 SYN이 버려진다 → 정상 사용자 접속 불가.

왜 되나? TCP는 상태(state)를 가진 프로토콜이라 서버가 3-way handshake를 완료하기 전에도 자원을 먼저 할당한다. 그리고 IP에는 출발지 인증이 없어 위조가 가능하다.

sequenceDiagram
    participant A as 공격자(위조 IP)
    participant S as 서버:80
    participant X as 위조된 IP(존재X)
    A->>S: SYN (src=1.2.3.4 위조)
    Note over S: 백로그 큐에 등록, SYN_RECV
    S->>X: SYN+ACK
    Note over X: 응답 없음(ACK 안 옴)
    A->>S: SYN (src=5.6.7.8 위조)
    A->>S: SYN (src=9.9.9.9 위조)
    Note over S: 큐 가득 참 - 정상 SYN 폐기

백로그 큐 그림

 서버의 Half-open 대기열 (backlog = 8 이라 가정)
 ┌────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┐
 │1.2.3.4 │5.6.7.8 │9.9.9.9 │7.7.1.2 │3.3.3.3 │8.1.1.9 │6.2.2.2 │4.4.4.4 │ ← 모두 SYN_RECV
 └────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┘
                                                        정상 사용자 SYN → ✗ DROP
 각 칸은 ACK가 올 때까지(또는 타임아웃까지) 비워지지 않는다.

탐지 1 — netstat -an (리눅스, 피해 서버에서)

$ netstat -an | grep ':80 '
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 192.168.10.5:80         45.33.12.7:38012        SYN_RECV
tcp        0      0 192.168.10.5:80         172.89.4.201:11930      SYN_RECV
tcp        0      0 192.168.10.5:80         61.19.200.33:52101      SYN_RECV
tcp        0      0 192.168.10.5:80         118.7.94.6:2304         SYN_RECV
tcp        0      0 192.168.10.5:80         10.20.30.40:51234       ESTABLISHED

$ netstat -an | grep SYN_RECV | wc -l
1024

• 읽는 법: SYN_RECV(윈도우는 SYN_RECEIVED) 상태가 비정상적으로 많고, Foreign Address가 제각각 무작위다 → 위조 IP 기반 SYN Flooding. 정상이라면 SYN_RECV는 순간적으로 몇 개만 보인다.

탐지 2 — tcpdump

$ tcpdump -nn -i eth0 'tcp[tcpflags] & tcp-syn != 0 and dst port 80'
14:02:11.000112 IP 45.33.12.7.38012 > 192.168.10.5.80: Flags [S], seq 1830219455, win 512, length 0
14:02:11.000118 IP 172.89.4.201.11930 > 192.168.10.5.80: Flags [S], seq 99812011, win 512, length 0
14:02:11.000124 IP 61.19.200.33.52101 > 192.168.10.5.80: Flags [S], seq 4012993871, win 512, length 0
14:02:11.000131 IP 192.168.10.5.80 > 45.33.12.7.38012: Flags [S.], seq 2210388210, ack 1830219456, win 64240, options [mss 1460], length 0
14:02:11.000135 IP 118.7.94.6.2304 > 192.168.10.5.80: Flags [S], seq 771203345, win 512, length 0

• Flags [S] = SYN, [S.] = SYN+ACK (tcpdump에서 .은 ACK), [R] = RST, [P.] = PSH+ACK, [F.] = FIN+ACK.
• 같은 마이크로초 단위로 출발지 IP·포트가 매번 다른 SYN이 쏟아지고, 그 뒤에 이어지는 ACK([.])가 없다 → SYN Flood.
• win 512, length 0처럼 모든 패킷이 똑같은 값이면 도구(hping 류)로 찍어낸 패킷일 가능성이 높다.

대응

1-4. Land 공격

• 원리: 출발지 IP·포트 = 목적지 IP·포트인 SYN 패킷을 보낸다. 피해자는 자기 자신에게 SYN+ACK를 보내고, 다시 그걸 받아 응답하는 무한 루프에 빠지거나 일부 구형 OS는 멈춘다.
• 왜 되나: 구형 TCP/IP 스택이 "출발지와 목적지가 같은 패킷"이라는 비정상 조건을 검사하지 않았다.
• 탐지: 패킷에서 src IP == dst IP (Snort sameip 옵션).
• 대응: 방화벽/라우터에서 출발지 = 목적지 패킷 차단, 외부에서 들어오는데 출발지가 내부 IP인 패킷 차단, OS 패치.

 [ src 192.168.10.5:80 → dst 192.168.10.5:80 , SYN ]
            └─────────── 같은 주소 ───────────┘

1-5. Smurf / Fraggle ★★★

Smurf 원리

1. 공격자는 ICMP Echo Request(type 8) 를 만든다. 출발지 IP는 피해자 IP로 위조.
2. 목적지는 증폭 네트워크의 Directed Broadcast 주소(예: 10.1.1.255)로 보낸다.
3. 그 네트워크의 라우터가 directed broadcast를 허용하면, 서브넷의 모든 호스트가 요청을 받는다.
4. 모든 호스트가 Echo Reply(type 0) 를 출발지 = 피해자에게 보낸다 → 1개 요청이 N배로 증폭.

                    ICMP Echo Request
 공격자 ───────────────────────────────────▶ 라우터 ── 10.1.1.255 (브로드캐스트)
 (src = 피해자 IP 위조)                         │
                                ┌───────────┬───┴───────┬───────────┐
                              호스트1     호스트2      호스트3 ...   호스트N   ← 증폭 네트워크
                                │           │           │           │
                                └─── Echo Reply × N ────┴───────────┘
                                              ▼
                                          ▶ 피해자 ◀  (대역폭 고갈)

Smurf 3요소 (암기): ICMP Echo + Directed Broadcast + 출발지 위조

• Fraggle: Smurf의 UDP 버전. 브로드캐스트로 UDP echo(7) 또는 chargen(19) 포트에 요청. chargen은 문자를 계속 생성해 돌려주므로 echo↔chargen 루프가 생길 수도 있다.
• 대응
  • 증폭 네트워크(중간 라우터): no ip directed-broadcast (Cisco IOS 12.0부터 기본값)
  • 호스트: 브로드캐스트 주소로 온 ICMP Echo에 응답하지 않음 (리눅스 net.ipv4.icmp_echo_ignore_broadcasts = 1)
  • 피해자 측: ICMP Echo Reply 임계치 제한, 상위 ISP 협조
  • 공통: 출발지 위조 차단(Ingress filtering)
  • Fraggle: 불필요한 echo/chargen 서비스 비활성화

1-6. Ping of Death

• 원리: IP 패킷의 최대 크기는 65,535바이트(Total Length 필드 16비트). 공격자는 단편(fragment)들을 조합하면 65,535를 넘게 되도록 ICMP를 보낸다. 마지막 단편의 오프셋 × 8 + 길이가 65,535를 넘어, 재조합 시 버퍼 오버플로 → 구형 시스템 다운.
• 한 번에 큰 패킷을 보낼 수 없으므로 반드시 단편화를 이용한다는 점이 핵심.
• 대응: OS 패치(재조합 시 길이 검사), 비정상적으로 큰 ICMP·단편화된 ICMP 차단.

1-7. Teardrop / Bonk / Boink ★★

정상 단편화 복습: 1500 MTU에서 4000바이트 데이터를 보내면 IP 헤더(20)를 뺀 1480바이트씩 나뉜다. Fragment Offset 필드는 8바이트 단위다.

 [정상]  ID=0x1a2b
 Frag1: MF=1, offset=0    (0×8=0)       → 데이터 0     ~ 1479
 Frag2: MF=1, offset=185  (185×8=1480)  → 데이터 1480  ~ 2959
 Frag3: MF=0, offset=370  (370×8=2960)  → 데이터 2960  ~ 3999
        0          1480         2960        4000
        |──Frag1───|────Frag2────|───Frag3───|   (빈틈·겹침 없음)

 [Teardrop]  ID=0x1a2b
 Frag1: MF=1, offset=0    → 데이터 0   ~ 1479
 Frag2: MF=0, offset=100  (100×8=800) , 길이 400 → 데이터 800 ~ 1199
        0       800    1200      1480
        |───────Frag1───────────|
                |Frag2|                ← Frag2가 Frag1 안에 통째로 겹침
 재조합 루틴: "이번 단편 끝(1200) - 이전 단편 끝(1480) = -280"
            → 음수 길이를 복사 크기로 사용 → 메모리 오류, 시스템 다운

• 원리: 단편의 Fragment Offset을 겹치게(overlap) 또는 틈(gap) 있게 조작해 재조합 시 오류를 일으킨다.
• Bonk: 단편들의 순서번호(오프셋)를 모두 같게(예: 계속 1번) 보내 재조합을 혼란시킴.
• Boink: 처음엔 정상 순서로 보내다가 중간부터 순서번호를 어긋나게 조작. (Bonk의 개량형)
• 대응: OS 패치(재조합 시 겹침·음수 길이 검사), IPS의 단편 재조합 후 검사, 비정상 단편 차단.

1-8. UDP / ICMP Flooding

• UDP Flooding: 무작위 포트로 대량 UDP 전송. UDP는 비연결형이라 handshake 없이 바로 보낼 수 있고, 닫힌 포트면 피해자가 ICMP Port Unreachable까지 만들어 보내느라 자원을 더 쓴다. 주목적은 대역폭 소진.
• ICMP Flooding: 대량 Echo Request. 피해자가 Echo Reply를 생성하며 CPU·대역폭 소모.
• 대응: 불필요한 UDP 서비스 차단, ICMP 속도 제한(rate-limit), 상위 회선에서 차단(클린존).

1-9. 애플리케이션 계층(L7) DDoS ★★

TCP 연결은 정상적으로 완료된 뒤 HTTP 요청으로 공격하므로 IP 위조가 불가능하다(3-way handshake를 끝내야 하므로). 대신 패킷 수가 적고 정상 요청과 비슷해 탐지가 어렵다.

Slowloris 요청 모습 (헤더가 끝나지 않음)

GET /index.html HTTP/1.1\r\n
Host: www.victim.example\r\n
User-Agent: Mozilla/5.0\r\n
X-a: b\r\n              ← 10초 후
X-c: d\r\n              ← 또 10초 후 ... 빈 줄(\r\n)은 영원히 안 옴

HTTP GET Flooding — Apache access.log 분석

203.0.113.45 - - [22/Dec/2026:14:03:11 +0900] "GET / HTTP/1.1" 200 5123 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
203.0.113.45 - - [22/Dec/2026:14:03:11 +0900] "GET / HTTP/1.1" 200 5123 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
203.0.113.45 - - [22/Dec/2026:14:03:11 +0900] "GET / HTTP/1.1" 200 5123 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
198.51.100.7 - - [22/Dec/2026:14:03:11 +0900] "GET /search.php?q=a83kd HTTP/1.1" 200 18233 "-" "-"
198.51.100.7 - - [22/Dec/2026:14:03:11 +0900] "GET /search.php?q=x1p0z HTTP/1.1" 503 299 "-" "-"

• 읽는 법(Combined 포맷): 출발지IP ident user [시간] "요청줄" 상태코드 응답크기 "Referer" "User-Agent"
• 같은 IP가 같은 초에 같은 URL을 반복 → GET Flooding.
• search.php?q=무작위값처럼 쿼리를 바꿔 캐시를 우회하고 DB 부하가 큰 페이지를 노림, User-Agent "-" (비어 있음) → 봇 의심.
• 결국 503(Service Unavailable) 이 등장 → 서버 자원 고갈.

# 초당 요청이 많은 IP 상위 5개 뽑기 (로그 분석 실기 단골)
$ awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -5
  48213 203.0.113.45
  31877 198.51.100.7
    142 10.20.30.40
     88 10.20.30.41
     51 10.20.30.77

1-10. DRDoS (반사·증폭) ★★★

sequenceDiagram
    participant A as 공격자/봇
    participant R as 반사 서버(DNS, NTP 등)
    participant V as 피해자
    A->>R: 작은 요청 60B (src=피해자 IP 위조)
    Note over R: 정상 요청으로 보고 응답
    R->>V: 큰 응답 3000B (증폭)
    A->>R: 작은 요청 반복
    R->>V: 큰 응답 반복
    Note over V: 요청한 적 없는 응답 폭주 - 대역폭 고갈

• UDP 기반 서비스가 반사체로 쓰인다. UDP는 handshake가 없어 출발지 위조 패킷에도 응답하기 때문이다(TCP는 SYN+ACK만 반사되어 증폭이 거의 없음).
• 증폭률 = 응답 크기 / 요청 크기

• TCP 기반 반사: 출발지를 피해자로 위조한 SYN을 다수 서버에 보내면 그 서버들의 SYN+ACK가 피해자에게 몰린다(증폭은 작지만 출발지가 정상 서버라 차단이 어려움).
• 대응 핵심: 반사체 측은 불필요한 UDP 서비스 차단·설정 강화, 네트워크 전체는 출발지 위조 패킷이 애초에 나가지 못하게(BCP38/uRPF), 피해자는 요청하지 않은 응답(예: 출발지 포트 53/123에서 오는 대량 UDP) 차단.

1-11. DDoS 공격 구조와 도구

           ┌──────────┐
           │  공격자   │  (Attacker / Client)
           └────┬─────┘
       명령 하달 │  (C&C 채널: IRC, HTTP, P2P ...)
      ┌─────────┼──────────┐
 ┌────▼───┐ ┌───▼────┐ ┌───▼────┐
 │마스터1 │ │마스터2 │ │마스터3 │   (Master / Handler / C&C 서버)
 └──┬──┬──┘ └──┬──┬──┘ └──┬──┬──┘
    │  │       │  │       │  │
   에이전트·데몬·좀비(봇) 수천 대    (Agent / Daemon / Bot)
    └──┴───────┴──┴───────┴──┘
               │ 동시 공격
               ▼
            [ 피해자 ]

• 공격자(Attacker): 전체 공격을 지휘. 마스터(Master, Handler): 공격자의 명령을 받아 에이전트를 관리. 에이전트(Agent, Daemon, 좀비): 실제 공격 패킷을 발생시키는 감염 PC.
• 현대에는 이 구조가 봇넷(Botnet) 과 C&C(Command & Control) 서버로 발전. IoT 기기를 감염시킨 Mirai(2016)가 대표 사례.

1-12. DDoS 대응 체계 ★★

① 단계별 대응

② 주요 기술

③ 출발지 IP 위조 방지 — Ingress/Egress 필터링, uRPF, BCP38 ★

• Ingress 필터링 (BCP38, RFC 2827): ISP나 기업 경계 라우터가 들어오는 패킷 중 출발지가 말이 안 되는 것(예: 외부에서 들어오는데 출발지가 내부 대역이거나 사설 IP·예약 IP)을 버린다. 원래 의미는 "고객 망에서 ISP로 들어오는 패킷의 출발지가 그 고객에게 할당된 대역인지 확인"이다.
• Egress 필터링: 내 망에서 나가는 패킷의 출발지가 내 대역이 아니면 버린다 → 내 망 PC가 좀비가 되어도 위조 패킷을 못 내보냄.
• uRPF (Unicast Reverse Path Forwarding): 라우터가 패킷의 출발지 IP로 가는 경로를 라우팅 테이블에서 역조회한다.
  • Strict 모드: 출발지로 가는 경로가 패킷이 들어온 바로 그 인터페이스여야 통과. 비대칭 라우팅 환경에서는 정상 패킷도 버릴 수 있음.
  • Loose 모드: 출발지로 가는 경로가 어느 인터페이스든 존재하기만 하면 통과(라우팅 불가 주소·Bogon만 차단).

           [uRPF Strict]
 패킷 도착: src=10.9.9.9, 입력 인터페이스 = Gi0/1
 라우팅 테이블 조회: 10.9.9.9 → Gi0/2 로 나가야 함
 → 들어온 곳(Gi0/1) ≠ 돌아갈 곳(Gi0/2) → DROP (위조로 판단)

⚠️ 시험 함정 (Day 1)

• Smurf = ICMP, Fraggle = UDP(7, 19). "UDP 브로드캐스트를 이용한 Smurf"라고 하면 틀린 보기.
• Smurf의 차단 지점은 증폭 네트워크 라우터(no ip directed-broadcast)다. 피해자 라우터가 아니다.
• Land = 출발지와 목적지가 같음, Teardrop = 오프셋 겹침, Ping of Death = 65,535 초과. 세 개를 섞어 내는 문제가 매번 나온다.
• SYN Flooding의 대응으로 "백로그 큐를 줄인다"는 틀림(늘린다). "SYN Cookie는 큐에 저장하고..."도 틀림(저장하지 않는다).
• HTTP GET Flood·Slowloris는 IP 위조가 불가능하다(3-way handshake 완료 필요). "출발지 IP를 위조하여 Slowloris…"는 오답.
• Slowloris = 헤더를 안 끝냄, RUDY = POST 바디를 느리게, Slow Read = 윈도우 크기를 작게. 대상을 바꿔 출제.
• DRDoS는 좀비 감염 없이도 가능하다. 반사 서버는 피해자가 아니라 "이용당하는" 정상 서버.
• uRPF Strict는 비대칭 라우팅에서 오탐(정상 차단) 가능, Loose는 경로 존재만 확인.
• Ingress 필터링 ≠ "내부로 들어오는 모든 트래픽 차단". 출발지 주소가 타당한지 보는 것.

📌 기출 포인트 (Day 1)

• 공격 설명을 주고 이름 고르기: 출발지=목적지(Land), 브로드캐스트+ICMP(Smurf), 오프셋 겹침(Teardrop), 헤더 미완성(Slowloris), 캐시 우회 헤더(CC Attack).
• SYN Flooding에서 서버가 머무는 TCP 상태(SYN_RECV) 와 대응(SYN Cookie, 백로그 증가) 고르기.
• 증폭 공격에 쓰이는 프로토콜과 명령(NTP monlist, DNS ANY/오픈 리졸버, Memcached 11211) 연결.
• DDoS 도구 특징(TFN2K·Stacheldraht의 암호화), 구성요소 명칭(공격자-마스터-에이전트).
• 클린존·uRPF·Ingress 필터링이 무엇을 막는 기술인지.
• 실기: netstat/tcpdump/access.log를 주고 공격명 + 판단 근거 + 대응 서술.

✏️ 확인 문제 (Day 1)

Q1. 다음 설명에 해당하는 공격은?
"공격자는 출발지 주소를 피해 시스템으로 위조한 ICMP Echo Request를 특정 네트워크의 브로드캐스트 주소로 전송한다."
① Land ② Smurf ③ Fraggle ④ Teardrop

Q2. SYN Flooding 공격에 대한 대응으로 옳지 않은 것은?
① SYN Cookie 기능을 활성화한다.
② 백로그 큐의 크기를 줄여 half-open 연결을 빨리 정리한다.
③ SYN+ACK 재전송 횟수를 줄여 대기 시간을 단축한다.
④ 출발지별 초당 SYN 패킷 수에 임계치를 둔다.

Q3. 다음 중 출발지 IP 위조가 사실상 불가능한 공격은?
① SYN Flooding ② Smurf ③ Slowloris ④ DNS 증폭 공격

Q4. IP 단편의 Fragment Offset 값을 서로 겹치게 조작해 재조합 과정에서 오류를 일으키는 공격은?
① Ping of Death ② Land ③ Teardrop ④ Fraggle

Q5. 라우터가 수신 패킷의 출발지 주소로 가는 경로를 라우팅 테이블에서 역조회하여, 그 경로가 패킷이 들어온 인터페이스와 다르면 폐기하는 기법은?
① uRPF Strict 모드 ② uRPF Loose 모드 ③ 블랙홀 라우팅 ④ Egress 필터링

Q6. DRDoS 공격에서 증폭률이 매우 커 2018년 대규모 공격에 사용되었고, UDP 11211 포트를 사용하는 서비스는?
① NTP ② SSDP ③ Memcached ④ CLDAP

Day 2 · 스캐닝

2-1. 개념: 공격 전에 지도를 그린다

공격자는 보통 다음 순서로 정보를 모은다.

 ① 풋프린팅 (Footprinting)  : 공개 정보 수집 — whois, DNS 조회(nslookup/dig), 검색엔진, 홈페이지, SNS
        ↓
 ② 스캐닝 (Scanning)        : 살아 있는 호스트 → 열린 포트 → 서비스·버전 → OS 확인
        ↓
 ③ 목록화 (Enumeration)     : 계정, 공유 폴더, 배너, SNMP 정보 등 구체적 정보 추출
        ↓
 ④ 취약점 스캔 / 공격

• 스캐닝의 원리: TCP/IP는 "열린 포트와 닫힌 포트에 다르게 응답하도록" 표준(RFC 793)에 정의되어 있다. 공격자는 일부러 특이한 패킷을 보내고 응답의 차이로 포트 상태를 알아낸다.
• RFC 793의 핵심 규칙 2개 (FIN/NULL/XMAS 스캔의 근거)
  1. 닫힌 포트는 RST가 아닌 패킷을 받으면 RST로 응답한다.
  2. 열린 포트는 SYN·RST·ACK가 모두 없는 이상한 패킷을 받으면 조용히 버린다(무응답).

2-2. 호스트 탐색 (Host Discovery, Ping Sweep)

• 도구: ping, fping(여러 호스트 동시), nmap -sn 192.168.0.0/24(포트 스캔 없이 호스트만), arp-scan.

2-3. 포트 스캔 종류별 동작 ★★★

포트 상태 (Nmap 표기)

(1) TCP Connect 스캔 -sT

운영체제의 connect() 시스템 콜을 그대로 써서 3-way handshake를 완료한다. 관리자 권한이 필요 없지만, 연결이 완성되므로 대상 서버의 애플리케이션 로그에 남는다.

sequenceDiagram
    participant N as 스캐너
    participant T as 대상
    Note over N,T: 열린 포트
    N->>T: SYN
    T->>N: SYN+ACK
    N->>T: ACK (연결 완료)
    N->>T: RST+ACK (바로 종료)
    Note over N,T: 닫힌 포트
    N->>T: SYN
    T->>N: RST+ACK

(2) TCP SYN 스캔 (Half-open, Stealth) -sS ★

SYN을 보내고 SYN+ACK가 오면 열린 것, 곧바로 RST를 보내 연결을 끊는다. 3-way handshake를 완료하지 않으므로 애플리케이션 로그에 남지 않는다(단, 방화벽·IDS에는 남는다). Raw 소켓이 필요해 root 권한 필요. Nmap의 기본 스캔(root일 때).

sequenceDiagram
    participant N as 스캐너
    participant T as 대상
    Note over N,T: 열린 포트
    N->>T: SYN
    T->>N: SYN+ACK
    N->>T: RST (완료하지 않고 끊음)
    Note over N,T: 닫힌 포트
    N->>T: SYN
    T->>N: RST+ACK
    Note over N,T: 필터링(방화벽)
    N->>T: SYN
    Note over T: 무응답 또는 ICMP Unreachable

(3) FIN / NULL / XMAS 스캔 -sF -sN -sX ★★

sequenceDiagram
    participant N as 스캐너
    participant T as 대상(리눅스/유닉스)
    Note over N,T: 열린 포트
    N->>T: FIN 또는 NULL 또는 FIN+PSH+URG
    Note over T: 무응답(조용히 버림)
    Note over N,T: 닫힌 포트
    N->>T: FIN 또는 NULL 또는 FIN+PSH+URG
    T->>N: RST+ACK

• 무응답이면 open|filtered, RST면 closed.
• Windows는 RFC를 따르지 않고 열린 포트에서도 RST를 보낸다 → 모든 포트가 closed로 보임. 거꾸로 이 특성으로 "대상이 Windows 계열"이라고 추정할 수 있다.
• SYN이 없어 단순 패킷 필터(SYN만 막는 규칙)를 우회할 수 있었던 것이 장점이지만, 상태 기반 방화벽은 세션 없는 FIN을 버린다.

(4) ACK 스캔 -sA — 방화벽 규칙 확인용

ACK만 보낸다. 열린 포트든 닫힌 포트든 필터가 없으면 RST가 돌아온다 → 열림/닫힘이 아니라 "필터링 여부" 를 알아낸다.

sequenceDiagram
    participant N as 스캐너
    participant F as 방화벽
    participant T as 대상
    N->>T: ACK
    T->>N: RST (unfiltered - 상태 없는 필터 통과)
    N->>F: ACK
    Note over F: 상태 기반 방화벽이 세션 없는 ACK 폐기
    Note over N: 무응답 = filtered

(5) UDP 스캔 -sU

UDP는 handshake가 없다. 닫힌 포트는 ICMP Port Unreachable(type 3, code 3) 를 돌려준다. 열린 포트는 보통 무응답(서비스가 응답하면 open 확정).

sequenceDiagram
    participant N as 스캐너
    participant T as 대상
    Note over N,T: 닫힌 포트
    N->>T: UDP 패킷
    T->>N: ICMP type3 code3 Port Unreachable
    Note over N,T: 열린 포트
    N->>T: UDP 패킷
    Note over T: 무응답(open 또는 filtered) 또는 UDP 응답(open)

• ICMP 응답을 초당 제한하는 OS(리눅스 기본 약 1개/초)가 많아 매우 느리다.

(6) Idle 스캔 -sI — 출발지를 완전히 숨김

IP 헤더의 Identification(IPID) 필드가 패킷마다 1씩 증가하는 "한가한(idle)" 좀비 호스트를 이용한다. 공격자 IP는 대상에게 전혀 노출되지 않는다.

sequenceDiagram
    participant A as 공격자
    participant Z as 좀비(한가한 호스트)
    participant T as 대상
    A->>Z: SYN+ACK (IPID 탐색)
    Z->>A: RST (IPID=1000)
    A->>T: SYN (src=좀비 IP로 위조)
    T->>Z: SYN+ACK (포트가 열린 경우)
    Z->>T: RST (IPID=1001 소비)
    A->>Z: SYN+ACK (다시 탐색)
    Z->>A: RST (IPID=1002)
    Note over A: 2 증가 = 열림, 1 증가 = 닫힘 또는 필터링

• 닫힌 포트면 대상이 좀비에게 RST를 보내고, 좀비는 RST에 응답하지 않으므로 IPID가 1만 증가.

(7) 그 밖의 회피 기법

2-4. 스캔 비교 요약표 ★

2-5. OS 핑거프린팅 · 서비스 확인

• 배너 그래빙 (Banner Grabbing): 서비스에 접속해 첫 응답(배너)으로 제품·버전 확인.

  $ nc 192.168.10.5 22
  SSH-2.0-OpenSSH_7.4
  $ nc 192.168.10.5 21
  220 (vsFTPd 2.3.4)
  

  → 대응: 배너에서 버전 정보 숨기기(예: Apache ServerTokens Prod, ServerSignature Off).
• 능동적(Active) 핑거프린팅: nmap -O. 특이한 패킷을 보내 응답의 미세한 차이를 데이터베이스와 비교 — TTL 초깃값, TCP 윈도우 크기, TCP 옵션 순서, DF 비트, IPID 증가 방식, 비정상 플래그에 대한 반응 등.
• 수동적(Passive) 핑거프린팅: p0f. 패킷을 보내지 않고 지나가는 트래픽만 관찰해 추정 → 탐지되지 않음.

수신된 TTL이 119면 128에서 9홉 지나온 것 → Windows 추정. 55면 64에서 9홉 → 리눅스 추정.

2-6. Nmap 주요 옵션

$ nmap -sS -sV -O 192.168.10.5
PORT     STATE    SERVICE  VERSION
22/tcp   open     ssh      OpenSSH 7.4 (protocol 2.0)
80/tcp   open     http     Apache httpd 2.4.6
443/tcp  closed   https
3306/tcp filtered mysql
OS details: Linux 3.10 - 4.11

• 22·80은 열림(SYN+ACK 받음), 443은 닫힘(RST 받음), 3306은 무응답(방화벽이 막음).

2-7. 스캔 탐지 — 패킷으로 읽기 ★ (실기)

SYN 스캔 tcpdump

10:15:01.100211 IP 203.0.113.9.51515 > 192.168.10.5.21: Flags [S], seq 3829110021, win 1024, options [mss 1460], length 0
10:15:01.100214 IP 203.0.113.9.51515 > 192.168.10.5.22: Flags [S], seq 3829110021, win 1024, options [mss 1460], length 0
10:15:01.100219 IP 203.0.113.9.51515 > 192.168.10.5.23: Flags [S], seq 3829110021, win 1024, options [mss 1460], length 0
10:15:01.100301 IP 192.168.10.5.21 > 203.0.113.9.51515: Flags [R.], seq 0, ack 3829110022, win 0, length 0
10:15:01.100305 IP 192.168.10.5.22 > 203.0.113.9.51515: Flags [S.], seq 1102938475, ack 3829110022, win 29200, options [mss 1460], length 0
10:15:01.100340 IP 203.0.113.9.51515 > 192.168.10.5.22: Flags [R], seq 3829110022, win 0, length 0
10:15:01.100355 IP 192.168.10.5.23 > 203.0.113.9.51515: Flags [R.], seq 0, ack 3829110022, win 0, length 0

• 같은 출발지(203.0.113.9)·같은 출발지 포트에서 목적지 포트만 21, 22, 23… 순차 증가 → 포트 스캔.
• 21·23: [R.] (RST+ACK) → 닫힘. 22: [S.] (SYN+ACK) → 열림, 바로 스캐너가 [R]을 보냄 → SYN(half-open) 스캔의 전형.
• win 1024, 같은 seq 값 반복 → 도구가 만든 패킷.

XMAS / NULL / FIN 스캔 tcpdump

10:20:44.501002 IP 203.0.113.9.40021 > 192.168.10.5.80: Flags [FPU], seq 912003, win 1024, urg 0, length 0
10:20:44.501090 IP 203.0.113.9.40021 > 192.168.10.5.81: Flags [FPU], seq 912003, win 1024, urg 0, length 0
10:20:44.501133 IP 192.168.10.5.81 > 203.0.113.9.40021: Flags [R.], seq 0, ack 912004, win 0, length 0
10:20:51.330017 IP 203.0.113.9.40022 > 192.168.10.5.80: Flags [none], win 1024, length 0
10:20:58.200450 IP 203.0.113.9.40023 > 192.168.10.5.80: Flags [F], seq 1500, win 1024, length 0

• [FPU] = FIN+PSH+URG → XMAS. 80번은 응답 없음(열림 추정), 81번은 RST(닫힘).
• [none] = 플래그 없음 → NULL 스캔. [F] 단독 → FIN 스캔(정상 종료라면 보통 [F.] FIN+ACK).

Wireshark 디스플레이 필터 (스캔 찾기)

2-8. 취약점 스캐너 · 스캔 도구

2-9. 스캔 대응

• 불필요한 서비스·포트 닫기, 방화벽 Default Deny, 관리 포트는 출발지 제한.
• 상태 기반 방화벽: 세션 없는 FIN/ACK/XMAS/NULL 패킷 폐기.
• IDS/IPS: 짧은 시간 안에 한 출발지가 많은 포트에 접속하는 패턴, 비정상 플래그 조합(XMAS·NULL·SYN+FIN) 탐지 (Snort 룰은 Day 5).
• 배너에서 버전 정보 제거, ICMP Echo·Timestamp 응답 제한.
• 호스트 측 탐지 도구: PortSentry(스캔 탐지 시 자동 차단), TCP Wrapper 로그.

⚠️ 시험 함정 (Day 2)

• FIN/NULL/XMAS에서 열린 포트 = 무응답, 닫힌 포트 = RST. 반대로 외우면 다 틀린다.
• UDP 스캔의 닫힌 포트 응답은 RST가 아니라 ICMP Port Unreachable(type 3 code 3).
• ACK 스캔은 포트가 열렸는지 알 수 없다. 방화벽(필터) 존재 여부만 안다.
• SYN 스캔에서 RST를 보내는 쪽은 스캐너(SYN+ACK를 받은 뒤). 대상이 RST를 보내면 닫힌 포트.
• "Stealth 스캔"은 로그가 전혀 안 남는다는 뜻이 아니다. 애플리케이션 로그에 덜 남을 뿐, 방화벽·IDS는 탐지한다.
• XMAS는 FIN·PSH·URG (ACK·SYN 아님). "모든 플래그"라고 하는 보기도 함정.
• FIN/NULL/XMAS는 Windows 대상에서 모두 closed로 보인다(효과 없음).
• Idle 스캔은 IPID를 이용 (TTL·순서번호 아님). Firewalking은 TTL 이용.
• Nikto는 웹 취약점 스캐너. Nessus/OpenVAS는 종합 취약점 스캐너. Nmap은 기본적으로 포트 스캐너.

📌 기출 포인트 (Day 2)

• 스캔 이름 ↔ 보내는 플래그 ↔ 열림/닫힘 응답을 표로 매칭.
• "로그가 남지 않도록 연결을 완료하지 않는 스캔"(SYN), "방화벽 필터링 여부"(ACK), "출발지 노출 없음"(Idle).
• TTL 64/128/255로 OS 추정, 능동/수동 핑거프린팅 구분.
• 취약점 스캐너 이름 고르기(Nessus, OpenVAS, Nikto)와 용도.
• 실기: tcpdump 줄을 주고 "어떤 스캔인가, 어느 포트가 열려 있나" 답하기.

✏️ 확인 문제 (Day 2)

Q1. 리눅스 서버를 대상으로 XMAS 스캔을 수행했을 때 닫힌 포트의 응답은?
① 무응답 ② SYN+ACK ③ RST+ACK ④ ICMP Port Unreachable

Q2. 다음 중 TCP 플래그 조합이 바르게 연결된 것은?
① NULL 스캔 – SYN ② XMAS 스캔 – FIN, PSH, URG ③ FIN 스캔 – FIN, ACK ④ ACK 스캔 – SYN, ACK

Q3. 스캐너가 보낸 패킷에 대해 대상이 RST를 보내면 "unfiltered", 무응답이면 "filtered"로 판단하며, 포트의 열림·닫힘보다 방화벽 규칙 파악에 쓰이는 스캔은?
① SYN 스캔 ② ACK 스캔 ③ UDP 스캔 ④ Connect 스캔

Q4. 다음 tcpdump 출력에 대한 해석으로 옳은 것은?
IP 10.0.0.9.4444 > 10.0.0.5.22: Flags [S] → IP 10.0.0.5.22 > 10.0.0.9.4444: Flags [S.] → IP 10.0.0.9.4444 > 10.0.0.5.22: Flags [R]
① 22번 포트가 닫혀 있어 대상이 RST를 보냈다.
② TCP Connect 스캔으로 연결이 완료되었다.
③ 22번 포트가 열려 있고, 스캐너가 연결을 완료하지 않고 끊었다.
④ XMAS 스캔이다.

Q5. 패킷을 보내지 않고 네트워크를 지나가는 트래픽의 TTL·윈도우 크기 등을 관찰하여 운영체제를 추정하는 기법과 도구가 바르게 짝지어진 것은?
① 능동적 핑거프린팅 – nmap -O ② 수동적 핑거프린팅 – p0f ③ 배너 그래빙 – Nikto ④ Firewalking – hping3

Day 3 · 스푸핑 · 스니핑 · 세션 하이재킹

복습: ARP 동작(Request는 브로드캐스트, Reply는 유니캐스트), 스위치의 MAC 주소 테이블, TCP 순서번호/확인응답번호 → Week01_네트워크 기초

3-1. 스니핑(Sniffing)의 원리

스니핑은 네트워크를 지나가는 패킷을 엿듣는(도청) 수동적 공격이다. 기밀성(C)을 노린다.

• 보통 NIC는 목적지 MAC이 자기 것이거나 브로드캐스트/멀티캐스트인 프레임만 받아들이고 나머지는 버린다.
• NIC를 무차별 모드(Promiscuous Mode) 로 바꾸면 자기 것이 아닌 프레임도 모두 상위 계층으로 올린다. 스니퍼는 이 모드를 사용한다.
• 허브(Hub) 환경: 허브는 받은 프레임을 모든 포트로 뿌리므로 무차별 모드만 켜면 다 보인다.
• 스위치(Switch) 환경: 스위치는 MAC 테이블을 보고 해당 포트로만 보내므로 무차별 모드만으로는 남의 트래픽이 안 보인다 → 공격자는 아래의 스위치 공격으로 트래픽을 자기에게 끌어온다.
• 평문 프로토콜(Telnet, FTP, HTTP, POP3, IMAP, SNMPv1/v2c)은 ID·PW가 그대로 노출된다.
• 도구: tcpdump, Wireshark, dsniff(계정 정보 추출 특화, arpspoof·macof·dnsspoof 등 포함), Ettercap, Cain & Abel.

3-2. 스위치 환경의 스니핑 기법 ★★

 [MAC Flooding]
 공격자 ── 초당 수만 개 프레임, 출발지 MAC 무작위 ──▶ 스위치
                                              CAM 테이블 (용량 예: 8K 항목)
                                              ┌──────────────────────┐
                                              │ 3a:1f:..  포트5        │
                                              │ 7c:22:..  포트5        │
                                              │ ... 가짜로 가득 참 ... │
                                              └──────────────────────┘
 정상 프레임(목적지 MAC 학습 불가) → "모르는 목적지" → 모든 포트로 플러딩 → 공격자도 수신

3-3. ARP 스푸핑 상세 ★★★

왜 되나?

1. ARP에는 인증이 없다 — 누가 보낸 Reply인지 확인하지 않는다.
2. ARP는 상태가 없다(stateless) — 내가 Request를 보낸 적이 없어도 Reply가 오면 캐시를 갱신한다(Gratuitous/Unsolicited ARP 수용).

공격 흐름 (게이트웨이와 피해자 사이 MITM)

sequenceDiagram
    participant V as 피해자 192.168.0.23
    participant A as 공격자 192.168.0.50
    participant G as 게이트웨이 192.168.0.1
    A->>V: ARP Reply "192.168.0.1은 aa-bb-cc-11-22-33"
    A->>G: ARP Reply "192.168.0.23은 aa-bb-cc-11-22-33"
    Note over A: 몇 초마다 반복 전송(캐시 유지)
    V->>A: 외부로 가는 패킷(목적지 MAC=공격자)
    Note over A: 패킷 복사/열람 후 IP 포워딩
    A->>G: 그대로 전달
    G->>A: 응답
    A->>V: 전달(피해자는 눈치 못 챔)

• 공격자는 IP 포워딩(리눅스 net.ipv4.ip_forward=1, 도구 fragrouter)을 켜서 받은 패킷을 원래 목적지로 넘겨준다. 그래야 통신이 끊기지 않아 들키지 않는다.

ARP 캐시: 공격 전 / 후 (피해자 PC에서 arp -a)

[공격 전]
C:\> arp -a
Interface: 192.168.0.23 --- 0xb
  Internet Address      Physical Address      Type
  192.168.0.1           00-1a-2b-3c-4d-5e     dynamic
  192.168.0.50          aa-bb-cc-11-22-33     dynamic
  192.168.0.255         ff-ff-ff-ff-ff-ff     static

[공격 후]
C:\> arp -a
Interface: 192.168.0.23 --- 0xb
  Internet Address      Physical Address      Type
  192.168.0.1           aa-bb-cc-11-22-33     dynamic   ← 게이트웨이 MAC이 바뀜!
  192.168.0.50          aa-bb-cc-11-22-33     dynamic   ← 공격자와 같은 MAC
  192.168.0.255         ff-ff-ff-ff-ff-ff     static

• 판단 근거: 서로 다른 IP(게이트웨이 .1과 .50)가 같은 MAC을 가진다 → ARP 스푸핑. 공격자는 .50이다.

탐지

• arp -a에서 MAC 중복, 게이트웨이 MAC 변경.
• arpwatch: IP-MAC 쌍 변화를 감시해 "flip flop", "changed ethernet address" 알림.
• Wireshark: arp.duplicate-address-detected 필터, 짧은 간격으로 반복되는 요청 없는 ARP Reply(arp.opcode == 2).
• 응답 시간(RTT)이 갑자기 늘어남, traceroute 첫 홉이 게이트웨이가 아닌 공격자 IP.

대응

• 정적 ARP 등록: 중요한 IP(게이트웨이)의 MAC을 고정.
  • 리눅스 arp -s 192.168.0.1 00:1a:2b:3c:4d:5e
  • 윈도우 netsh interface ipv4 add neighbors "Ethernet" 192.168.0.1 00-1a-2b-3c-4d-5e (구형 arp -s)
  • 단점: 호스트가 많으면 관리가 어렵고, 재부팅 시 사라질 수 있음.
• DAI (Dynamic ARP Inspection): 스위치가 DHCP Snooping 바인딩 테이블(IP-MAC-포트)과 비교해 맞지 않는 ARP를 폐기.
• 포트 보안, 내부망 암호화(SSH, TLS, IPSec) — 가로채도 내용을 못 보게.

3-4. ICMP 리다이렉트 공격

• ICMP Redirect(type 5)는 원래 "같은 네트워크에 더 좋은 게이트웨이가 있다"고 라우터가 호스트에게 알려주는 메시지다.
• 공격자가 라우터인 척 Redirect를 위조해 보내면 피해자의 라우팅 테이블에 "목적지 X로 가려면 공격자를 거쳐라"가 추가된다.
• ARP 스푸핑은 2계층(MAC), ICMP 리다이렉트는 3계층(라우팅 테이블) 을 조작한다는 차이.
• 대응: Redirect 수신 무시 — 리눅스 net.ipv4.conf.all.accept_redirects = 0, send_redirects = 0(라우터가 아닌 호스트).

3-5. IP 스푸핑과 트러스트(Trust) 공격

• IP 스푸핑: 패킷의 출발지 IP를 위조. 단독으로는 응답을 받을 수 없어(응답이 진짜 IP로 감) 주로 DoS나, IP만으로 인증하는 서비스를 노린다.
• 트러스트 관계: 유닉스 r 명령(rlogin, rsh, rexec)은 /etc/hosts.equiv, ~/.rhosts에 등록된 호스트에서 오면 비밀번호 없이 로그인을 허용했다.
• 고전적 공격 순서 (1994년 미트닉 사례로 유명)
  1. 신뢰받는 호스트 B를 SYN Flooding으로 마비(B가 RST를 못 보내게).
  2. 서버 A의 ISN(초기 순서번호) 패턴을 예측.
  3. 출발지를 B로 위조해 A에 SYN → A의 SYN+ACK는 B로 가지만 B는 마비 상태.
  4. 공격자는 예측한 순서번호로 ACK를 보내 연결 완료 → rsh로 .rhosts에 + + 추가 등.
• 대응: 트러스트(r 계열 서비스) 제거하고 SSH 사용, ISN 랜덤화, 경계에서 내부 IP를 출발지로 한 외부 유입 패킷 차단(Ingress 필터링).

3-6. DNS 스푸핑 / DNS 캐시 포이즈닝 ★★

DNS 스푸핑 (LAN 내 경쟁 조건, Race)

DNS는 주로 UDP 53을 쓰고, 클라이언트는 먼저 도착한 응답을 믿고 나중 응답은 버린다. 공격자가 같은 LAN에서 (ARP 스푸핑 등으로) DNS 질의를 엿보면 트랜잭션 ID와 포트를 그대로 맞춘 가짜 응답을 진짜 DNS 서버보다 먼저 보낼 수 있다.

sequenceDiagram
    participant V as 피해자
    participant A as 공격자(스니핑 중)
    participant D as 정상 DNS 서버
    V->>D: Query bank.example A? (TXID 0x3f1a)
    Note over A: 질의를 엿보고 TXID와 포트 확인
    A->>V: 가짜 Response 1.2.3.4 (TXID 0x3f1a)
    D->>V: 진짜 Response 203.0.113.80 (TXID 0x3f1a)
    Note over V: 먼저 온 가짜를 채택, 진짜는 폐기
    V->>A: 가짜 사이트(1.2.3.4) 접속 - 파밍

DNS 캐시 포이즈닝

• 개별 PC가 아니라 DNS 캐시 서버(리졸버)의 캐시를 오염시킨다 → 그 서버를 쓰는 모든 사용자가 가짜 IP를 받는다(TTL 동안).
• 원격 공격자는 TXID(16비트=65,536가지)를 모르므로 추측해서 대량의 위조 응답을 보낸다. 카민스키 공격(2008) 은 존재하지 않는 무작위 하위 도메인(a1.bank.example, a2.bank.example …)을 계속 질의하게 만들어 시도 횟수를 무제한으로 늘리고, 위조 응답의 권한(Authority) 영역에 도메인 전체의 NS를 공격자 서버로 넣었다.

3-7. 스니핑 탐지 기법 ★★

 [Ping 이용 탐지]
 탐지자 → 목적지 IP = 192.168.0.50 (의심 호스트)
          목적지 MAC = 00:00:00:aa:bb:cc  (아무도 안 쓰는 가짜 MAC)
 정상 NIC        : "내 MAC 아님" → 버림 → 응답 없음
 무차별 모드 NIC : 모든 프레임 수신 → IP가 자기 것 → Echo Reply 응답 → 스니퍼 확정

• 근본 대응은 암호화: Telnet → SSH, FTP → SFTP/FTPS, HTTP → HTTPS, 네트워크 구간 IPSec/VPN. 스위치 환경 유지, 포트 보안.

3-8. 세션 하이재킹 (TCP Session Hijacking) ★★

개념: 이미 인증이 끝난 TCP 세션을 중간에서 빼앗는다. 비밀번호를 몰라도 로그인된 세션을 그대로 쓴다. 핵심은 TCP가 패킷의 정당성을 IP·포트·순서번호(SEQ)·확인응답번호(ACK) 만으로 판단한다는 점이다.

순서번호 흐름 (같은 LAN에서 스니핑하며 수행하는 경우)

 클라이언트 10.0.0.10:51000  ⇄  서버 10.0.0.20:23 (Telnet, 이미 로그인됨)

 ① C → S : SEQ=1000, ACK=5000, 데이터 10바이트("ls -al\r\n" 등)
 ② S → C : SEQ=5000, ACK=1010, 데이터 200바이트
   (서버는 다음에 SEQ=1010을 기대, 클라이언트는 다음에 SEQ=5200을 기대)

 ③ 공격자 → S : (출발지 10.0.0.10:51000 위조) SEQ=1010, ACK=5200, 데이터 "명령" 20바이트
      → 서버는 정상으로 받아들임. 이제 서버가 기대하는 다음 SEQ=1030

 ④ 진짜 C → S : SEQ=1010 ... (서버 입장에선 이미 지난 번호 = 범위 밖)
      → 서버: "내가 기대하는 건 1030" ACK=1030 으로 응답
      → 클라이언트: "난 1010까지만 보냈는데?" 자기 기준 ACK로 응답
      → 서로 상대 ACK가 틀렸다며 ACK를 주고받는 무한 반복 = ACK Storm

• 비동기화(Desynchronization): 클라이언트와 서버가 기대하는 SEQ/ACK가 서로 어긋난 상태. 공격자만 올바른 번호를 알고 있다.
  • 초기 비동기화(Early Desync): 연결 초기에 공격자가 서버에 RST를 보내고 다른 ISN으로 새 연결을 열어 어긋나게 만듦.
  • 널 데이터 비동기화(Null Data Desync): 의미 없는 데이터를 양쪽에 보내 번호만 증가시킴.
• ACK Storm: 비동기화 상태에서 양쪽이 ACK를 끝없이 주고받는 현상 → 세션 하이재킹의 탐지 단서. 패킷 유실이 생기면 결국 멈추기도 한다.
• 공격자는 하이재킹 중 클라이언트 쪽에 RST를 보내 연결을 끊어버리기도 한다(사용자는 "연결이 끊겼다"고만 느낌).
• 도구: Hunt, Ettercap, Shijack, Juggernaut.

sequenceDiagram
    participant C as 클라이언트
    participant A as 공격자
    participant S as 서버
    C->>S: SEQ=1000 ACK=5000 (10B)
    S->>C: SEQ=5000 ACK=1010 (200B)
    A->>S: 위조 SEQ=1010 ACK=5200 (20B 명령)
    Note over S: 다음 기대 SEQ=1030
    C->>S: SEQ=1010 (서버 기준 범위 밖)
    S->>C: ACK=1030
    C->>S: ACK=5200 (자기 기준)
    Note over C,S: ACK Storm 반복

탐지: ACK Storm(비정상적으로 많은 ACK), 패킷 유실·재전송 급증, 갑작스러운 세션 끊김, 같은 세션에서 TTL이 다른 패킷(출발지가 달라짐) 혼재.
대응: 암호화(SSH·TLS — 공격자가 유효한 암호문을 못 만듦), 중요 작업 시 재인증, 세션 타임아웃, 스니핑 방지(스위치 보안), ISN 랜덤화.

웹 세션 하이재킹: 로그인 후 받는 세션 쿠키(예: JSESSIONID)를 XSS·스니핑으로 훔쳐 재사용. 대응: 쿠키 Secure·HttpOnly·SameSite, HTTPS 전 구간, IP/User-Agent 바인딩, 로그인 시 세션 ID 재발급.

3-9. 원격 접속 공격: 트로이목마 · 백도어 · 리버스 쉘

 [바인드 쉘]   공격자 ──(인바운드, 방화벽 차단 ✗)──▶ 피해자:4444 LISTEN
 [리버스 쉘]   피해자 ──(아웃바운드 443, 방화벽 통과 ✓)──▶ 공격자:443 LISTEN

탐지 — 수상한 외부 연결 찾기

C:\> netstat -ano | findstr ESTABLISHED
  TCP    192.168.0.23:49822     198.51.100.66:443      ESTABLISHED     4312
  TCP    192.168.0.23:49830     52.97.12.4:443         ESTABLISHED     6020

C:\> tasklist /FI "PID eq 4312"
Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
svch0st.exe                   4312 Console                    1      6,212 K

• PID 4312의 프로세스 이름이 svchost.exe가 아니라 svch0st.exe(숫자 0) — 정상 프로세스 위장. 알 수 없는 외부 IP 443에 상시 연결 → 리버스 연결 의심.

$ netstat -antp | grep ESTABLISHED
tcp   0   0 10.0.5.21:43122   203.0.113.250:4444   ESTABLISHED 2231/bash

• bash 프로세스가 직접 외부 4444 포트와 연결 → 정상적인 셸은 네트워크 소켓을 직접 쥐지 않으므로 리버스 쉘 의심.

대응: Egress(아웃바운드) 필터링(필요한 목적지·포트만 허용, 프록시 경유 강제), 최소 권한, 무결성 점검(Tripwire), EDR, 열린 포트·프로세스 정기 점검(netstat, lsof -i), 출처 불명 프로그램 실행 금지.

3-10. 스푸핑 공격 비교 요약

⚠️ 시험 함정 (Day 3)

• ARP 스푸핑은 ARP Reply를 위조한다(Request 위조라고 하면 틀린 경우가 많음). 그리고 ARP는 요청하지 않은 Reply도 받아들인다는 점이 원인.
• 정적 ARP는 arp -s, 삭제는 arp -d. arp -a는 조회.
• MAC Flooding의 결과는 스위치가 허브처럼 동작(모든 포트로 전송)하는 것이지, 스위치가 멈추는 것이 아니다. 대응은 포트 보안.
• ICMP Redirect는 type 5. Echo Request(8)·Port Unreachable(3/3)과 혼동 주의.
• 스니핑 탐지의 Ping 방법은 "존재하지 않는 MAC으로, 의심 호스트 IP에" 보낸다. IP를 가짜로 하는 것이 아님. DNS 방법은 "가짜 IP를 뿌리고 역질의"를 본다.
• ACK Storm은 세션 하이재킹의 결과/징후이지 별도 DoS 공격 이름이 아니다.
• DNSSEC은 무결성·출처 인증을 제공하고 기밀성(암호화)은 제공하지 않는다.
• 리버스 쉘이 방화벽을 우회하는 이유는 아웃바운드 연결이기 때문. 대응은 Egress 필터링.
• 트로이목마는 자기 복제를 하지 않는다.

📌 기출 포인트 (Day 3)

• ARP 캐시 출력을 보고 공격 판단(MAC 중복), 정적 ARP 명령어.
• 스위치 환경 스니핑 기법 4종(스위치 재밍, ARP 스푸핑, ARP 리다이렉트, ICMP 리다이렉트)과 SPAN.
• 스니핑 탐지 방법(Ping/ARP/DNS/유인/ARPWatch)의 원리 서술.
• DNS 스푸핑이 성공하는 이유(먼저 온 응답 채택, UDP)와 DNSSEC.
• 세션 하이재킹의 비동기화와 ACK Storm, 대응.
• 리버스 쉘·백도어의 개념과 아웃바운드 통제.

✏️ 확인 문제 (Day 3)

Q1. 다음 arp -a 결과에 대한 설명으로 가장 적절한 것은?

192.168.0.1     aa-bb-cc-11-22-33   dynamic
192.168.0.50    aa-bb-cc-11-22-33   dynamic

① 정상적인 상태이다. ② 192.168.0.1이 ARP 스푸핑 공격을 수행 중이다. ③ 192.168.0.50 호스트가 게이트웨이로 위장하는 ARP 스푸핑이 의심된다. ④ MAC Flooding 공격이 진행 중이다.

Q2. 스위치에 위조된 출발지 MAC 주소를 가진 프레임을 대량으로 보내 스위치가 허브처럼 동작하게 만드는 공격과 그 대응이 바르게 연결된 것은?
① ARP 리다이렉트 – 정적 ARP ② 스위치 재밍 – 포트 보안 ③ ICMP 리다이렉트 – DAI ④ DHCP 스푸핑 – DNSSEC

Q3. 스니퍼 탐지 기법 중 "의심 호스트의 IP 주소로, 그러나 존재하지 않는 MAC 주소를 목적지로 하여 ICMP Echo Request를 보낸다"는 방법의 원리는?
① 스니퍼는 역방향 DNS 질의를 하기 때문이다.
② 무차별 모드의 NIC는 목적지 MAC이 달라도 프레임을 수신하므로 응답하게 된다.
③ 스니퍼는 ARP 캐시를 비우기 때문이다.
④ 스니퍼는 TTL을 변경하기 때문이다.

Q4. TCP 세션 하이재킹 과정에서 클라이언트와 서버가 서로 상대방의 순서번호가 틀렸다고 판단하여 ACK 패킷을 계속 주고받는 현상은?
① SYN Storm ② ACK Storm ③ Broadcast Storm ④ RST Flood

Q5. DNS 캐시 포이즈닝에 대한 대응으로 가장 거리가 먼 것은?
① DNSSEC 적용 ② DNS 질의의 출발지 포트 랜덤화 ③ 외부 사용자의 재귀 질의 허용 ④ 트랜잭션 ID 랜덤화

Q6. 내부 감염 PC가 외부 공격자 서버의 443 포트로 먼저 접속하여 명령 실행 환경을 넘겨주는 방식에 대한 설명으로 옳은 것은?
① 바인드 쉘이며, 인바운드 차단으로 쉽게 막을 수 있다.
② 리버스 쉘이며, 아웃바운드(Egress) 통제가 효과적인 대응이다.
③ IP 스푸핑이며, uRPF로 막을 수 있다.
④ 세션 하이재킹이며, ACK Storm이 발생한다.

Day 4 · 보안 장비

4-1. 방화벽(Firewall)의 개념과 기능

방화벽은 신뢰하는 내부망과 신뢰하지 않는 외부망 경계에서 미리 정한 보안 정책(규칙) 에 따라 트래픽을 허용·차단하는 시스템이다.

방화벽의 한계 (자주 출제)

• 내부자 공격은 막지 못한다(경계를 지나지 않음).
• 방화벽을 거치지 않는 우회 경로(무선 AP, 개인 모뎀, USB)는 통제 불가.
• 허용된 포트로 들어오는 악성 내용(바이러스, 웹 공격)은 패킷 필터형이 탐지 못 함.
• 암호화된 트래픽 내용은 검사 불가(복호화 기능 제외).
• 새로운 형태의 공격에 대한 사전 대응 한계.

4-2. 방화벽 종류 ★★

상태 기반 방화벽의 세션 테이블 예

 Proto  Source             Destination        State
 TCP    10.0.0.23:51022    93.184.216.34:443  ESTABLISHED
 TCP    10.0.0.31:40110    203.0.113.5:80     SYN_SENT
 UDP    10.0.0.23:53001    8.8.8.8:53         (응답 대기, 30초)
 → 외부에서 93.184.216.34:443 → 10.0.0.23:51022 로 오는 응답은 테이블에 있으므로 허용
 → 테이블에 없는 외부발 ACK/FIN 패킷은 차단 (ACK·FIN 스캔 무력화)

4-3. 방화벽 구성 형태 ★★★

① 스크리닝 라우터 (Screening Router)

 인터넷 ──── [스크리닝 라우터: 패킷 필터링] ──── 내부망

• 라우터의 ACL로 3·4계층 필터링. 저렴·빠름, 그러나 라우터 하나 뚫리면 끝, 로그·인증 약함.

② 배스천 호스트 (Bastion Host)

• 외부에 노출되어 공격을 직접 받는 요새(성채) 호스트. 불필요한 서비스를 모두 제거하고 강화(Hardening) 된 시스템. 프록시·인증·로그 기능 수행.

③ 이중 홈 게이트웨이 (Dual-Homed Gateway)

 인터넷 ──── [NIC1  배스천 호스트  NIC2] ──── 내부망
                  (IP 포워딩 OFF, 프록시로만 중계)

• NIC 2개를 가진 배스천 호스트. 라우팅 기능을 끄고 프록시로만 통신 → 내부/외부 직접 연결 불가. 호스트 하나가 뚫리면 내부 노출(단일 장애점).

④ 스크린드 호스트 게이트웨이 (Screened Host Gateway)

 인터넷 ── [스크리닝 라우터] ──┬── 내부망
                              │
                        [배스천 호스트]
   라우터: "외부→내부 트래픽은 반드시 배스천 호스트로만" (패킷 필터 + 프록시 2단)

• 스크리닝 라우터(1차 패킷 필터) + 내부망의 배스천 호스트(2차 프록시). 이중 방어, 그러나 라우터가 뚫려 정책이 바뀌면 배스천을 우회해 내부로 직행 가능.

⑤ 스크린드 서브넷 게이트웨이 (Screened Subnet Gateway) — DMZ

 인터넷
   │
 [외부 스크리닝 라우터]
   │
 ──┴─────── DMZ (경계 네트워크) ──────────────
     │            │             │
 [배스천 호스트] [웹 서버]   [메일·DNS 서버]
 ──┬────────────────────────────────────────
   │
 [내부 스크리닝 라우터]
   │
 내부망 (DB, 업무 PC)

• 두 라우터(또는 방화벽) 사이에 DMZ(Demilitarized Zone) 라는 완충 서브넷을 둔다. 외부에 공개할 서버는 DMZ에, 중요한 자산은 내부망에.
• 가장 안전(공격자는 두 겹을 뚫어야 함), 그러나 구축 비용·관리 복잡도가 가장 크고 속도 저하.
• 현대에는 방화벽 1대에 인터페이스 3개(외부/DMZ/내부)로 구성하는 3-Leg(Three-legged) 형태도 흔하다.

4-4. 방화벽 정책과 룰 처리 순서 ★

• 기본 정책: Default Deny(명시적으로 허용한 것 외 모두 거부)가 원칙. 반대는 Default Allow(블랙리스트).
• 처리 순서: 규칙을 위에서부터 순서대로(Top-down) 비교하여 처음 일치한 규칙(First Match) 을 적용하고 나머지는 보지 않는다. 어느 규칙과도 맞지 않으면 마지막의 묵시적 거부(Implicit Deny).
• 따라서 구체적인 규칙을 위에, 일반적인 규칙을 아래에 둔다. 자주 맞는 규칙을 위로 올리면 성능에도 좋다.

예제 룰셋

3번 "악성 대역 차단" 의도가 있었다면 1번보다 위에 둬야 한다. 아래 규칙이 위 규칙에 가려져 영원히 적용되지 않는 현상을 규칙 가림(Shadowing) 이라 한다.

4-5. IDS (Intrusion Detection System) ★★★

개념: 네트워크·시스템을 감시하여 침입(의심) 행위를 탐지하고 알리는 시스템. 기본은 탐지·경고이며 차단은 하지 않는다(일부는 TCP RST 전송·방화벽 연동 같은 제한적 대응).

구성 요소

• 센서/에이전트 (데이터 수집) → 분석 엔진 (탐지) → 관리 콘솔 (경고, 정책 관리) → DB (시그니처, 로그)

처리 단계 (순서 문제 단골)

 ① 정보 수집 (Data Collection)        : 패킷·로그·시스템 호출 수집
        ↓
 ② 정보 가공 및 축약 (Data Reduction)  : 필터링, 불필요 정보 제거, 정규화
        ↓
 ③ 분석 및 침입 탐지 (Analysis)        : 오용/이상 탐지 기법 적용
        ↓
 ④ 보고 및 대응 (Reporting/Response)  : 경고, 로그, (방화벽 연동, RST 전송)

분류 1 — 데이터 출처(설치 위치)

분류 2 — 탐지 방식 ★★★

오탐 / 미탐 (2×2) ★

• False Negative(미탐)가 더 위험하다 — 공격이 아무 경고 없이 성공한다.
• False Positive가 너무 많으면 관리자가 경보를 무시하게 되는 경보 피로(Alert Fatigue) 문제.
• 임계치를 낮추면(민감하게) 오탐↑ 미탐↓, 높이면 오탐↓ 미탐↑ — 트레이드오프.

4-6. IPS와 배치 위치 ★★

 [IDS — Out-of-band(수동) 배치]

 인터넷 ── 방화벽 ── 스위치 ──────── 내부 서버
                       │ (SPAN/미러 포트 또는 TAP으로 복사본 전달)
                       ▼
                     [IDS] → 경보만 (원본 트래픽 흐름에 관여 X)

 [IPS — In-line 배치]

 인터넷 ── 방화벽 ── [IPS] ── 스위치 ── 내부 서버
                      ↑ 모든 트래픽이 통과 → 탐지 즉시 해당 패킷/세션 Drop

• SPAN(포트 미러링): 스위치가 트래픽 사본을 지정 포트로 복사. 저렴하지만 과부하 시 유실. TAP: 회선에 끼우는 전용 하드웨어 복사 장치, 유실 적음.
• WIPS: 무선 침입 방지 (비인가 AP, Evil Twin 탐지·차단).

4-7. 허니팟 (Honeypot)

• 공격자를 끌어들이기 위해 일부러 취약하게 보이도록 만든 유인 시스템. 실제 서비스가 없으므로 허니팟에 오는 접근은 모두 의심 대상 → 오탐이 거의 없다.
• 목적: 공격자 유인·지연, 공격 기법 수집·분석, 실제 자산으로부터 주의 분산.
• 조건: 공격자에게 매력적이어야 하고, 모든 행위가 기록·감시되어야 하며, 허니팟이 다른 시스템 공격의 발판이 되지 않도록 격리.
• 종류: 저상호작용(서비스 흉내, 안전) / 고상호작용(실제 OS, 정보 많지만 위험). 허니넷(허니팟 여러 대로 구성한 네트워크), 타르핏(Tarpit)(연결을 아주 느리게 붙잡아 스캐너·웜을 지연, 예 LaBrea).
• 설치 위치: DMZ 또는 내부망(내부 확산 탐지).

4-8. ESM · SIEM · SOAR ★

• 상관 분석(Correlation) 예: "같은 IP가 ① 방화벽에서 포트 스캔 탐지 → ② 5분 내 웹서버 로그인 실패 50회 → ③ 이후 로그인 성공" 을 하나의 고위험 사건으로 묶음. 개별 장비 이벤트로는 놓치는 공격을 찾는다.
• SOC(Security Operations Center): 이 장비들로 24시간 보안 관제를 수행하는 조직.

4-9. UTM · WAF

• UTM (Unified Threat Management, 통합 위협 관리): 방화벽 + IPS + VPN + 안티바이러스 + 안티스팸 + 웹 필터링 등을 하나의 장비에 통합.
  • 장점: 비용·관리 단순화, 중소기업에 적합. 단점: 단일 장애점, 모든 기능 켜면 성능 저하, 각 기능의 전문성은 전용 장비보다 낮을 수 있음.
• ESM vs UTM: ESM은 여러 장비의 이벤트(로그)를 통합 관리, UTM은 기능 자체를 한 장비에 통합. 혼동 단골.
• WAF (Web Application Firewall): HTTP/HTTPS 요청·응답을 7계층에서 검사 → SQL 인젝션, XSS, 파일 업로드, 디렉터리 탐색 등 웹 공격 차단, 응답의 개인정보 유출 차단. 예: ModSecurity(오픈소스). 일반 방화벽은 80/443을 열어두면 그 안의 웹 공격을 못 본다.

4-10. NAC (Network Access Control) ★★

개념: 네트워크에 접속하려는 단말(엔드포인트) 이 인가된 사용자·기기인지, 보안 정책(백신 설치·최신 패치·필수 SW·OS 설정) 을 지키는지 접속 전에 검사하고, 미준수 단말은 격리 → 치료 후 허용한다.

동작 단계

sequenceDiagram
    participant E as 단말(사용자 PC)
    participant N as NAC 정책 서버
    participant SW as 스위치/AP
    E->>SW: 네트워크 접속 시도
    SW->>N: 인증 요청(802.1X, MAC 등)
    N->>E: 사용자·기기 인증
    N->>E: 무결성 검사(백신, 패치, 필수SW)
    alt 정책 준수
        N->>SW: 정상 VLAN 허용
    else 미준수
        N->>SW: 격리 VLAN 할당
        Note over E: 패치·백신 업데이트(치료) 후 재검사
    end

• 주요 기능: 접근 제어(인증), 단말 무결성 검사, 격리(Quarantine) 및 치료(Remediation), 단말 가시성(자산 식별), 사후 감시(접속 후에도 정책 위반 시 차단).
• 구현 방식: 802.1X(스위치 포트 인증, EAP + RADIUS), 에이전트 설치형 / 에이전트리스, 인라인(게이트웨이)형, 아웃오브밴드형(ARP Enforcement — 미인가 단말에 위조 ARP를 보내 통신 차단, SPAN 감시, DHCP 기반).
• 방화벽은 "어디로 가는 트래픽인가"를, NAC는 "누가(어떤 단말이) 접속하는가"를 통제.

4-11. DLP (Data Loss Prevention)

• 기업 내부의 중요 정보(개인정보, 기밀 문서)가 외부로 유출되는 것을 탐지·차단. 정규식(주민번호 패턴), 키워드, 문서 핑거프린팅, 분류 라벨 기반.
• 데이터 상태별: Data in Motion(네트워크 전송 중 — 메일·웹 업로드), Data at Rest(저장 중 — 서버·DB 스캔), Data in Use(사용 중 — 복사·출력·USB·캡처).
• 유형: 네트워크 DLP(게이트웨이), 엔드포인트 DLP(PC 에이전트: USB·출력 통제), 스토리지 DLP.
• 방화벽·IPS가 들어오는 공격을 본다면, DLP는 나가는 데이터를 본다.

4-12. IP 역추적 (IP Traceback)

공격자가 IP를 위조하거나 여러 시스템을 경유(Stepping Stone) 하면 실제 근원지를 찾기 어렵다. 역추적은 크게 둘로 나뉜다.

• 실제 운영에서는 기술적 역추적보다 ISP·수사기관 협조, 로그 보존이 핵심. 예방책은 출발지 위조 자체를 막는 Ingress 필터링.

4-13. 장비 한눈 비교

⚠️ 시험 함정 (Day 4)

• 애플리케이션 게이트웨이는 7계층, 서킷 게이트웨이는 5계층(SOCKS). 서킷 게이트웨이를 "내용까지 검사"한다고 하면 틀림.
• 가장 안전한 구성 = 스크린드 서브넷, 하지만 "비용이 가장 적다"는 틀림. DMZ가 등장하면 스크린드 서브넷.
• 이중 홈 게이트웨이는 IP 포워딩(라우팅)을 끈다. 켜면 의미가 없음.
• 방화벽 룰은 첫 번째로 일치한 규칙만 적용(가장 엄격한 규칙이 아님). 순서 문제에서 함정.
• 오용 탐지 = 오탐 적음/신종 못 잡음, 이상 탐지 = 신종 탐지/오탐 많음. 반대로 섞은 보기 매번 출제.
• False Positive = 오탐(정상을 공격으로), False Negative = 미탐(공격을 놓침). 영어-한글 짝을 바꿔 출제. 더 위험한 것은 미탐.
• IDS 처리 단계 순서: 수집 → 가공·축약 → 분석·탐지 → 보고·대응. "분석 후 축약" 같은 순서 뒤섞기 주의.
• HIDS는 암호화 통신 내용을 볼 수 있다(호스트에서 복호화된 상태로 확인). NIDS는 못 본다.
• ESM(이벤트 통합) ≠ UTM(기능 통합). SIEM의 핵심어는 상관 분석, SOAR의 핵심어는 자동화·플레이북.
• NAC는 접속 전 단말 검사, DLP는 데이터 유출 통제. 둘 다 "내부"가 대상이라 헷갈리게 출제.
• 허니팟은 오탐이 거의 없다(정상 사용자가 접근할 이유가 없으므로).

📌 기출 포인트 (Day 4)

• 방화벽 유형별 계층과 특징, 상태 기반 방화벽의 상태 테이블 역할.
• 방화벽 구성 그림/설명 주고 이름 고르기(스크린드 호스트 vs 스크린드 서브넷), 배스천 호스트 정의.
• 룰셋을 주고 특정 패킷의 허용/차단 판정.
• IDS 탐지 방식 비교, 오탐/미탐 정의, 처리 단계 순서, HIDS/NIDS 장단점.
• IDS vs IPS 배치(SPAN·TAP vs 인라인), Fail-Open.
• ESM/SIEM/SOAR/UTM/NAC/DLP 정의 매칭, 허니팟 조건.
• 실기: 방화벽 정책 설계(DMZ 구성), IDS 오탐 원인과 튜닝 서술.

✏️ 확인 문제 (Day 4)

Q1. 두 개의 스크리닝 라우터 사이에 DMZ라는 완충 네트워크를 두고, 그 안에 배스천 호스트와 공개 서버를 배치하는 방화벽 구성은?
① 스크리닝 라우터 ② 이중 홈 게이트웨이 ③ 스크린드 호스트 게이트웨이 ④ 스크린드 서브넷 게이트웨이

Q2. 다음 방화벽 규칙에서 출발지 198.51.100.5, 목적지 10.0.1.10:80 패킷의 처리 결과는?
1) deny 198.51.100.0/24 → any any / 2) allow any → 10.0.1.10 tcp/80 / 3) deny any → any any
① 2번 규칙에 따라 허용 ② 1번 규칙에 따라 거부 ③ 3번 규칙에 따라 거부 ④ 가장 구체적인 2번 규칙이 우선하여 허용

Q3. 이상 탐지(Anomaly Detection) 방식 IDS에 대한 설명으로 옳은 것은?
① 알려진 공격 시그니처와 비교하므로 오탐이 적다.
② 정상 행위 프로파일과의 차이로 판단하므로 알려지지 않은 공격도 탐지할 수 있다.
③ 시그니처 업데이트가 없으면 동작하지 않는다.
④ 대표 기법으로 패턴 매칭과 상태 전이 분석이 있다.

Q4. IDS가 실제 공격을 정상 트래픽으로 판단해 경보를 발생시키지 않은 경우를 뜻하는 용어는?
① True Positive ② False Positive ③ False Negative ④ True Negative

Q5. 다음 설명에 해당하는 것은?
"단말이 네트워크에 접속하기 전에 사용자 인증과 함께 백신 설치 여부, OS 패치 상태 등을 검사하고, 정책을 준수하지 않으면 격리 네트워크로 보내 치료 후 접속을 허용한다."
① DLP ② NAC ③ ESM ④ UTM

Q6. IPS를 인라인으로 배치할 때 장비 장애로 서비스가 중단되는 것을 막기 위해, 장애 시 트래픽을 검사 없이 통과시키는 설정은?
① Fail-Closed ② Fail-Open ③ SPAN ④ Shadowing

Day 5 · 보안 프로토콜 · VPN · Snort

5-1. SSL/TLS 개요

SSL/TLS는 전송 계층(TCP)과 응용 계층 사이에서 동작하며, 응용 프로토콜(HTTP, SMTP, IMAP, FTP 등)에 기밀성·무결성·서버(및 선택적 클라이언트) 인증을 제공한다. HTTPS = HTTP over TLS (TCP 443).

5-2. TLS 프로토콜 구조 ★★

 ┌───────────────┬──────────────────┬──────────┬──────────────┐
 │ Handshake(22) │ ChangeCipherSpec │ Alert(21)│ Application  │ ← 상위 프로토콜
 │               │      (20)        │          │  Data (23)   │   (괄호 = Content Type 값)
 ├───────────────┴──────────────────┴──────────┴──────────────┤
 │                   Record Protocol                          │ ← 하위: 실제 전송 담당
 ├────────────────────────────────────────────────────────────┤
 │                        TCP                                 │
 └────────────────────────────────────────────────────────────┘

Record 프로토콜 처리 순서

 응용 데이터 → ① 단편화(최대 2^14 = 16KB) → ② 압축(선택, 현재는 미사용)
            → ③ MAC 계산·추가 → ④ 암호화 → ⑤ 레코드 헤더(타입·버전·길이) 추가 → TCP

5-3. TLS 1.2 핸드셰이크 ★★★

sequenceDiagram
    participant C as 클라이언트
    participant S as 서버
    C->>S: ClientHello (버전, Client Random, 지원 암호스위트, 세션ID)
    S->>C: ServerHello (선택한 버전·암호스위트, Server Random)
    S->>C: Certificate (서버 인증서)
    S->>C: ServerKeyExchange (DHE/ECDHE 파라미터, 서명)
    S->>C: CertificateRequest (선택 - 클라이언트 인증 시)
    S->>C: ServerHelloDone
    C->>S: Certificate (요청받은 경우)
    C->>S: ClientKeyExchange (Pre-Master Secret 또는 DH 공개값)
    C->>S: CertificateVerify (클라이언트 인증 시)
    C->>S: ChangeCipherSpec
    C->>S: Finished (암호화됨, 핸드셰이크 전체 해시)
    S->>C: ChangeCipherSpec
    S->>C: Finished (암호화됨)
    Note over C,S: 이후 Application Data 암호화 통신 - 2-RTT

• 키 생성: Pre-Master Secret + Client Random + Server Random → Master Secret → 세션키(암호화키, MAC키, IV) 생성.
• RSA 키 교환: 클라이언트가 Pre-Master Secret을 서버 공개키로 암호화해 보냄 → 서버 개인키가 나중에 유출되면 과거 기록한 통신까지 모두 복호화 가능 (전방 비밀성 X). ServerKeyExchange 없음.
• (EC)DHE 키 교환: 매 세션 임시 DH 키 사용 → 완전 순방향 비밀성(PFS).
• Finished: 지금까지 주고받은 핸드셰이크 메시지 전체의 해시를 암호화해 보냄 → 중간에 협상이 변조(다운그레이드)되지 않았는지 확인.
• 세션 재개: 세션 ID 또는 세션 티켓으로 전체 핸드셰이크 생략(1-RTT).

암호 스위트 읽기

 TLS _ ECDHE _ RSA _ WITH _ AES_128_GCM _ SHA256
       키교환   인증          대칭 암호(모드)   해시(PRF/MAC)

5-4. TLS 1.3의 변경점 ★

sequenceDiagram
    participant C as 클라이언트
    participant S as 서버
    C->>S: ClientHello + key_share (DH 공개값 미리 전송)
    S->>C: ServerHello + key_share
    S->>C: (암호화) EncryptedExtensions, Certificate, CertificateVerify, Finished
    C->>S: (암호화) Finished
    Note over C,S: 1-RTT 만에 암호 통신 시작

5-5. SSL/TLS 공격 ★★

SSL Stripping과 HSTS

 사용자 ──HTTP──▶ [공격자(MITM)] ──HTTPS──▶ 은행 서버
   ▲  "http://bank.example" (평문)      서버와는 정상 암호 통신
   └─ 공격자는 응답 안의 https:// 링크를 http:// 로 바꿔 계속 평문 유지 → ID/PW 탈취

• HSTS(HTTP Strict Transport Security): 서버가 응답 헤더로 "앞으로 이 도메인은 HTTPS로만 접속하라"고 지시 → 브라우저가 이후 http:// 입력도 자동으로 https로 변환.

  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  

  • max-age: 기억 기간(초), includeSubDomains: 하위 도메인 포함, preload: 브라우저 내장 목록 등록(첫 접속까지 보호).

점검 실습

$ openssl s_client -connect www.example.com:443 -tls1
... handshake failure        ← TLS 1.0 거부됨(정상)
$ nmap --script ssl-enum-ciphers -p 443 www.example.com   ← 지원 버전·스위트 목록

• Wireshark: tls.handshake.type == 1(ClientHello), tls.handshake.type == 2(ServerHello), tls.record.content_type == 21(Alert).

5-6. IPSec ★★★

IPSec은 3계층(IP) 에서 동작하는 보안 프로토콜 모음이다. IP 위의 모든 트래픽(TCP, UDP, ICMP…) 을 애플리케이션 수정 없이 보호한다. IPv6에서는 원래 필수 구현, IPv4에서는 선택.

구성 요소

• 재전송 공격 방지: AH·ESP 헤더의 순서번호(Sequence Number) + 슬라이딩 윈도우.

IKE 동작 (IKEv1)

• Phase 1: 두 피어 간 안전한 관리 채널(ISAKMP SA / IKE SA) 생성. Main Mode(6개 메시지, 신원 보호) 또는 Aggressive Mode(3개 메시지, 빠르지만 신원 노출). DH 키 교환 + 인증(사전 공유키·인증서).
• Phase 2: Phase 1 채널 안에서 실제 데이터용 IPSec SA 생성. Quick Mode(3개 메시지).
• IKEv2: IKE_SA_INIT + IKE_AUTH 총 4개 메시지로 간소화, NAT-T·DoS 방어(쿠키) 내장.

5-7. 전송 모드 vs 터널 모드 — 패킷 구조 ★★★

 원래 패킷:            [ IP 헤더 | TCP 헤더 | 데이터 ]

 ── 전송 모드 (Transport) : 원래 IP 헤더 유지, 페이로드만 보호 ──
 AH  전송: [ IP 헤더 | AH | TCP | 데이터 ]
           |<──────── 인증 범위(IP 헤더의 가변 필드 제외 전체) ────────>|

 ESP 전송: [ IP 헤더 | ESP 헤더 | TCP | 데이터 | ESP 트레일러 | ESP 인증 ]
                              |<──── 암호화 범위 ────────>|
                     |<────────── 인증 범위 ─────────────>|

 ── 터널 모드 (Tunnel) : 원래 IP 패킷 전체를 감싸고 새 IP 헤더 추가 ──
 AH  터널: [ 새 IP 헤더 | AH | 원래 IP 헤더 | TCP | 데이터 ]
           |<──────────────── 인증 범위(전체) ────────────────>|

 ESP 터널: [ 새 IP 헤더 | ESP 헤더 | 원래 IP 헤더 | TCP | 데이터 | ESP 트레일러 | ESP 인증 ]
                                  |<──────────── 암호화 범위 ──────────>|
                       |<───────────────── 인증 범위 ──────────────────>|

• ESP 트레일러 = 패딩 + 패딩 길이 + Next Header. ESP 인증 = ICV(무결성 검사값).
• ESP 터널 모드는 원래 IP 헤더까지 암호화 → 실제 출발지·목적지 내부 주소가 숨겨짐 → 사이트 간 VPN의 표준.

IPSec과 NAT 문제 / NAT-T ★

• AH + NAT = 불가: AH는 IP 헤더의 출발지·목적지 주소까지 인증하는데 NAT가 주소를 바꾸면 무결성 검증 실패.
• ESP + NAT(PAT): ESP는 포트 번호가 없어(TCP/UDP 헤더가 암호화됨) NAPT가 세션을 구분하지 못함.
• NAT-T (NAT Traversal): ESP 패킷을 UDP 4500으로 한 번 더 감싸서 NAT 장비를 통과시킨다. IKE가 NAT 존재를 감지하면 500 → 4500으로 전환.

 NAT-T: [ IP | UDP 4500 | ESP 헤더 | (암호화된 데이터) | ESP 트레일러 | ESP 인증 ]

5-8. VPN ★★

VPN(Virtual Private Network): 인터넷 같은 공중망 위에 터널링 + 암호화 + 인증 + 접근 제어로 전용선처럼 쓰는 가상 사설망.

 [사이트 간 VPN (Site-to-Site)]
 본사 LAN ── [VPN 게이트웨이] ═══ IPSec 터널(인터넷) ═══ [VPN 게이트웨이] ── 지사 LAN

 [원격 접속 VPN (Remote Access / Client-to-Site)]
 재택 PC(VPN 클라이언트/브라우저) ═══ SSL VPN 또는 IPSec 터널 ═══ [VPN 게이트웨이] ── 사내망

5-9. Snort 룰 ★★★ (실기)

Snort: 오픈소스 NIDS/NIPS. 모드: ① 스니퍼 모드(화면 출력), ② 패킷 로거 모드(파일 저장), ③ NIDS 모드(룰로 탐지), ④ 인라인 모드(IPS, drop 가능).

룰 구조

 alert  tcp  $EXTERNAL_NET  any  ->  $HOME_NET  80  ( msg:"..."; content:"..."; sid:1000001; rev:1; )
 └액션┘ └프로토콜┘ └출발지 IP┘ └포트┘ └방향┘ └목적지 IP┘ └포트┘ └──────────── 룰 옵션 ────────────┘
 |<──────────────────────── 룰 헤더 ────────────────────────>|

주요 옵션

threshold의 type

• limit: 기간 내 처음 N번까지만 경보.
• threshold: N번마다 경보 (N, 2N, 3N…).
• both: 기간 내 N번에 도달하면 한 번만 경보 (flood 탐지에 적합).

offset / depth / distance / within 그림

 페이로드:  G  E  T     /  a  d  m  i  n  /  l  o  g  i  n  .  p  h  p
 바이트:    0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20

 content:"GET"; offset:0; depth:3;     → 0~2 바이트 안에서만 "GET" 검색 → 일치
 content:"admin"; offset:4; depth:10;  → 4~13 바이트 범위에서 "admin" 검색 → 5~9에서 일치
 content:"login"; distance:1; within:6; → 직전 일치 끝(9) 다음부터 1바이트 건너 10부터, 6바이트(10~15) 안 → 11~15 일치

룰 예제 (필드별 해설)

① 웹 명령 실행 시도 탐지

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"WEB-ATTACK cmd.exe 접근 시도"; flow:to_server,established; content:"cmd.exe"; nocase; classtype:web-application-attack; sid:1000001; rev:1;)

• 외부(any 포트) → 내부 80번, 연결이 수립된 뒤 서버로 가는 데이터 중 cmd.exe(대소문자 무시)가 있으면 경보.

② SYN Flooding 탐지 (threshold)

alert tcp any any -> $HOME_NET 80 (msg:"DoS SYN Flooding 의심"; flags:S; threshold:type both, track by_dst, count 200, seconds 1; sid:1000002; rev:1;)

• flags:S: SYN만 설정된 패킷. track by_dst: 목적지(피해 서버) 기준으로 셈 → 출발지가 위조로 흩어져도 집계됨. 1초에 200개 이상이면 그 기간에 한 번 경보.

③ XMAS / NULL 스캔 탐지

alert tcp any any -> $HOME_NET any (msg:"SCAN XMAS"; flags:FPU; sid:1000003; rev:1;)
alert tcp any any -> $HOME_NET any (msg:"SCAN NULL"; flags:0; sid:1000004; rev:1;)
alert tcp any any -> $HOME_NET any (msg:"SCAN SYN-FIN 비정상 조합"; flags:SF; sid:1000005; rev:1;)

• flags:FPU: FIN·PSH·URG가 정확히 설정. flags:0: 플래그 없음. SYN+FIN이 동시에 설정된 패킷은 정상 통신에 없으므로 스캔/회피 시도.

④ Land 공격 탐지

alert ip any any -> $HOME_NET any (msg:"DoS Land Attack"; sameip; sid:1000006; rev:1;)

⑤ FTP root 로그인 시도 (offset/depth)

alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP root 로그인 시도"; flow:to_server,established; content:"USER root"; nocase; offset:0; depth:9; sid:1000007; rev:1;)

• USER root(9바이트)가 페이로드 맨 앞 9바이트 안에 있을 때만 일치 → 다른 위치의 우연한 문자열은 무시(오탐 감소, 성능 향상).

⑥ SSH 무차별 대입 탐지 (by_src)

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"SSH Brute Force 의심"; flow:to_server; flags:S; threshold:type threshold, track by_src, count 5, seconds 60; sid:1000008; rev:1;)

• 같은 출발지가 60초 안에 SSH로 SYN을 5번 보낼 때마다 경보.

⑦ 큰 ICMP Echo (Ping of Death 류)

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP Large Echo Request"; itype:8; dsize:>800; sid:1000009; rev:1;)

⑧ HTTP GET Flooding

alert tcp any any -> $HOME_NET 80 (msg:"HTTP GET Flooding"; flow:to_server,established; content:"GET "; offset:0; depth:4; threshold:type both, track by_src, count 100, seconds 1; sid:1000010; rev:1;)

⑨ 차단(인라인 IPS) — 디렉터리 탐색

drop tcp any any -> $HOME_NET 80 (msg:"WEB 디렉터리 탐색 차단"; flow:to_server,established; content:"../"; content:"/etc/passwd"; distance:0; sid:1000011; rev:1;)

• 첫 content 뒤 어디서든(distance:0) /etc/passwd가 나오면 패킷 폐기.

Snort 경보 로그 읽기 (alert 파일, fast 형식)

12/22-14:02:11.000131  [**] [1:1000002:1] DoS SYN Flooding 의심 [**] [Priority: 0] {TCP} 45.33.12.7:38012 -> 192.168.10.5:80

• [1:1000002:1] = [GID:SID:REV]. 1은 룰 엔진(일반 룰), 1000002는 sid, 1은 rev.

5-10. iptables ★★★ (실기)

구조: 리눅스 커널의 Netfilter를 제어하는 명령. 테이블 → 체인 → 규칙 구조.

 들어온 패킷 → [PREROUTING] → 라우팅 판단 ─┬─ 나에게 → [INPUT] → 로컬 프로세스 → [OUTPUT] ─┐
                                         └─ 남에게 → [FORWARD] ──────────────────────────┴→ [POSTROUTING] → 나감

iptables도 위에서부터 처음 일치한 규칙을 적용한다(LOG는 기록 후 다음 규칙으로 계속 진행). 일치하는 것이 없으면 체인의 기본 정책(-P).

예제 규칙

# ① 기본 정책: 들어오는 것과 지나가는 것은 모두 차단 (Default Deny)
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# ② 루프백 허용
iptables -A INPUT -i lo -j ACCEPT

# ③ 상태 기반: 이미 수립된 연결과 관련 연결(FTP 데이터, ICMP 오류)은 허용
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#   (신형 문법) iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j DROP

# ④ SSH는 관리망에서만
iptables -A INPUT -p tcp -s 10.0.0.0/8 --dport 22 -j ACCEPT

# ⑤ SYN Flooding 완화: SYN을 초당 10개(버스트 20)로 제한
iptables -N SYN_FLOOD
iptables -A INPUT -p tcp --syn -j SYN_FLOOD
iptables -A SYN_FLOOD -m limit --limit 10/s --limit-burst 20 -j RETURN
iptables -A SYN_FLOOD -j LOG --log-prefix "SYN_FLOOD_DROP: "
iptables -A SYN_FLOOD -j DROP

# ⑥ 웹 서비스 허용 + 출발지 IP당 동시 연결 30개 초과 차단 (HTTP Flood, Slowloris 완화)
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 30 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

# ⑦ SSH 무차별 대입: 60초 안에 새 연결 5회 이상이면 차단
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --name SSH -j DROP

# ⑧ 비정상 플래그(스캔) 차단
iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP     # XMAS
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP            # NULL
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP     # SYN+FIN

# ⑨ ICMP Echo 초당 1개로 제한 (ICMP Flood/Smurf 완화)
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

# ⑩ 위조 출발지 차단: 외부 인터페이스로 사설 대역이 출발지인 패킷 (Ingress 필터링)
iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP

# ⑪ NAT: 내부망이 외부로 나갈 때 공인 IP로 변환 / 외부 8080 → 내부 웹서버 80 포트포워딩
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.10:80

• ⑤ 해설: --syn은 "SYN=1, ACK·RST·FIN=0"인 패킷. limit는 토큰 버킷 — 처음 20개(burst)까지 바로 통과, 이후 초당 10개씩 충전. 초과분은 RETURN 되지 못하고 LOG 후 DROP.
• ⑦ 해설: -I로 넣었으므로 나중에 넣은 DROP 규칙이 더 위에 위치한다. --set은 출발지를 목록에 기록, --update --hitcount 5는 60초 안에 5회째부터 일치.
• ③을 ④~⑥보다 위에 두는 이유: 대부분의 패킷은 이미 수립된 연결의 패킷이므로 맨 위에서 빨리 허용하면 성능이 좋고, 응답 패킷을 일일이 허용할 필요가 없다.

규칙 확인 출력 읽기

# iptables -L INPUT -n -v --line-numbers
Chain INPUT (policy DROP 1532 packets, 91920 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      120  9840 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
2     8812 4105K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
3       14   840 ACCEPT     tcp  --  *      *       10.0.0.0/8           0.0.0.0/0            tcp dpt:22
4      532 31920 SYN_FLOOD  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02
5      530 31800 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443

• policy DROP 1532 packets: 어느 규칙과도 맞지 않아 기본 정책으로 버려진 패킷 수.
• tcp flags:0x17/0x02: --syn의 실제 의미 — 마스크 0x17(FIN·SYN·RST·ACK) 중 SYN(0x02)만 설정.

DROP vs REJECT: DROP은 무응답이라 스캐너가 filtered로 판단하고 타임아웃까지 기다리게 됨(정보 노출 최소). REJECT는 즉시 거부 응답(RST/ICMP)을 보내 closed로 보이며 내부 사용자에겐 친절하다.

⚠️ 시험 함정 (Day 5)

• AH는 암호화를 하지 않는다. "AH는 기밀성을 제공한다"는 오답. AH = 51, ESP = 50 (숫자 뒤바꿈 주의).
• 터널 모드 = 새 IP 헤더 + 원래 패킷 전체 보호 = 게이트웨이 간 VPN. 전송 모드는 호스트 간.
• AH가 NAT와 충돌하는 이유는 IP 헤더(주소)까지 인증하기 때문. NAT-T는 UDP 4500.
• SA는 단방향. 양방향 통신에는 최소 2개.
• IKE는 UDP 500(TCP 아님). PPTP는 TCP 1723 + GRE, L2TP는 UDP 1701, L2TP는 자체 암호화가 없다.
• PPTP·L2F·L2TP = 2계층, IPSec = 3계층, SSL VPN = 4~7계층(응용).
• TLS ChangeCipherSpec은 Handshake 프로토콜의 메시지가 아니라 별도의 하위 프로토콜(TLS 1.2까지).
• Record 프로토콜 순서: 단편화 → 압축 → MAC → 암호화 ("암호화 후 MAC"이 아님 — TLS 1.2 기본 기준).
• Heartbleed는 SSL/TLS 프로토콜 설계 결함이 아니라 OpenSSL 구현 버그. POODLE은 SSL 3.0, BEAST는 TLS 1.0.
• TLS 1.3은 RSA 키 교환·CBC·압축·재협상 제거. "TLS 1.3은 RSA 인증서를 쓸 수 없다"는 틀림(RSA 서명은 가능, RSA 키 교환만 제거).
• Snort 방향 연산자는 ->와 <>뿐. 사용자 sid는 1,000,000 이상. depth는 offset 기준점부터의 길이.
• iptables DROP은 응답 없음, REJECT는 응답 있음. -A는 끝에 추가, -I는 맨 앞 삽입.

📌 기출 포인트 (Day 5)

• SSL/TLS 하위 프로토콜 4개의 역할, 핸드셰이크 메시지 순서 배열.
• 취약점 이름 ↔ 대상 버전/원인 매칭(Heartbleed·POODLE·BEAST·SSL Stripping), HSTS.
• AH/ESP 기능 비교표, 전송/터널 모드 패킷 구조, SA·SPD·IKE 정의, NAT-T.
• VPN 프로토콜 ↔ 계층 매칭.
• 실기: Snort 룰 빈칸 채우기·해석(flags, threshold, content/offset/depth), iptables 규칙 작성(특정 IP만 SSH 허용, SYN 제한, ESTABLISHED 허용).

✏️ 확인 문제 (Day 5)

Q1. IPSec의 AH 프로토콜에 대한 설명으로 옳지 않은 것은?
① IP 프로토콜 번호 51을 사용한다. ② 데이터 무결성과 출처 인증을 제공한다. ③ 페이로드를 암호화하여 기밀성을 제공한다. ④ NAT 환경에서 무결성 검증 문제가 발생한다.

Q2. 원래 IP 패킷 전체를 암호화하고 새로운 IP 헤더를 붙여, 두 보안 게이트웨이 사이의 VPN 구성에 주로 쓰이는 IPSec 조합은?
① AH 전송 모드 ② AH 터널 모드 ③ ESP 전송 모드 ④ ESP 터널 모드

Q3. TLS 1.3에서 제거되지 않은 것은?
① 정적 RSA 키 교환 ② CBC 모드 암호 스위트 ③ TLS 수준 압축 ④ (EC)DHE 키 교환

Q4. 다음 Snort 룰에 대한 설명으로 옳은 것은?
alert tcp any any -> $HOME_NET 22 (msg:"SSH BF"; flags:S; threshold:type threshold, track by_src, count 5, seconds 60; sid:1000008;)
① 목적지 기준으로 60초에 5번 SYN이 오면 경보한다.
② 동일 출발지에서 60초 동안 SYN 패킷 5개마다 경보한다.
③ SYN+ACK 패킷을 탐지한다.
④ sid 값이 공식 룰 범위에 해당하므로 오류이다.

Q5. 리눅스 서버에서 이미 연결된 세션의 응답 패킷을 허용하는 iptables 규칙은?
① iptables -A INPUT -m state --state NEW -j ACCEPT
② iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
③ iptables -P INPUT ACCEPT
④ iptables -A OUTPUT -m state --state INVALID -j ACCEPT

Q6. VPN 프로토콜과 동작 계층의 연결이 옳지 않은 것은?
① PPTP – 2계층 ② L2TP – 2계층 ③ IPSec – 3계층 ④ SSL VPN – 2계층

Day 6 · 2027 신규 범위 (기출에 없음)

2027~2029 출제기준에서 새로 명시되었거나 강조된 항목. 복원 기출이 거의 없으므로 정의·비교 위주로 정확히 잡아두고, 실기용 도구 사용법은 손으로 써본다.

오늘 체크리스트

• SDN 구조와 보안 위협
• NetBIOS·SMB·P2P
• 무선 LAN 보안 (WEP~WPA3, Evil Twin)
• 네트워크 진단 도구 (ping·traceroute·netstat·arp·tcpdump·Wireshark)
• 로그·패킷·악성코드 분석 도구
• SASE · ZTNA · XDR · EDR
• (실기) 클라우드 VPC · Security Group · NACL

6-1. SDN (Software Defined Networking) 보안

개념: 전통적인 네트워크 장비는 한 장비 안에 "어디로 보낼지 결정하는 두뇌(제어부)"와 "실제로 보내는 몸(전달부)"이 함께 있다. SDN은 이를 분리하여, 중앙의 SDN 컨트롤러가 소프트웨어로 전체 네트워크의 경로·정책을 결정하고, 스위치는 컨트롤러가 내려준 플로우 테이블대로 패킷만 전달한다.

 ┌────────────────────────────────────────────┐
 │  응용 계층 (Application Plane)              │  방화벽 앱, 로드밸런서, 모니터링
 └──────────────────┬─────────────────────────┘
                    │  Northbound API (REST 등)
 ┌──────────────────▼─────────────────────────┐
 │  제어 계층 (Control Plane) = SDN 컨트롤러    │  ONOS, OpenDaylight — 전체 망 시야
 └──────────────────┬─────────────────────────┘
                    │  Southbound API (OpenFlow 등)
 ┌──────────────────▼─────────────────────────┐
 │  데이터 계층 (Data Plane) = 스위치들         │  플로우 테이블대로 전달만
 └────────────────────────────────────────────┘

• OpenFlow: 컨트롤러와 스위치 사이 표준 프로토콜(Southbound). 스위치는 플로우 테이블에 없는 패킷을 만나면 컨트롤러에 Packet-In으로 물어보고, 컨트롤러는 Flow-Mod로 규칙을 내려준다.
• 보안상 장점: 중앙에서 정책 일괄 적용, 공격 트래픽을 즉시 격리·우회(동적 대응), 네트워크 전체 가시성.

• 관련 개념 NFV(Network Function Virtualization): 방화벽·라우터 같은 장비 기능을 범용 서버의 가상 머신/소프트웨어로 구현. SDN(제어 분리)과 상호 보완.

6-2. NetBIOS · NetBEUI · SMB · P2P

SMB 관련 주요 취약점·공격

 # 인터넷 경계에서 NetBIOS/SMB 차단 (iptables)
 iptables -A INPUT -i eth0 -p udp -m multiport --dports 137,138 -j DROP
 iptables -A INPUT -i eth0 -p tcp -m multiport --dports 139,445 -j DROP

P2P(Peer-to-Peer): 중앙 서버 없이 사용자 PC끼리 직접 파일을 주고받는 구조(BitTorrent 등).

• 보안 위협: 악성코드 유포(정상 파일로 위장), 공유 폴더 설정 실수로 내부 자료 유출, 대역폭 과다 사용, 저작권 문제, 동적 포트로 방화벽 우회.
• 대응: P2P 프로그램 사용 금지 정책, 애플리케이션 식별형 방화벽(NGFW)·DPI로 P2P 트래픽 차단, DLP.

6-3. 무선 LAN 보안 ★

WEP 크래킹 개념

1. WEP는 RC4(IV 24비트 ‖ 공유키)로 키스트림을 만든다. IV는 평문으로 전송된다.
2. IV가 2^24(약 1,677만) 가지뿐이라 트래픽이 많으면 같은 IV가 재사용되고, 특정 약한 IV는 키 바이트 정보를 흘린다(FMS/PTW 공격).
3. 공격자는 패킷을 수집(필요하면 ARP 재전송으로 트래픽을 인위적으로 늘림)하고 통계적으로 키를 복구한다. 도구 Aircrack-ng.
   → 결론: WEP는 어떤 설정으로도 안전하지 않다 → WPA2/WPA3 사용.

WPA2-PSK 공격 개념: 사용자가 AP에 연결할 때의 4-way handshake를 캡처(필요하면 Deauth로 재연결 유도) → 오프라인에서 사전 대입(Dictionary) 으로 비밀번호 추측. 비밀번호가 길고 복잡하면 실패. WPA3-SAE는 이 오프라인 대입을 막는다.

무선 공격 유형

sequenceDiagram
    participant U as 사용자 단말
    participant E as Evil Twin(가짜 AP, 같은 SSID)
    participant R as 정상 AP
    E->>U: Deauth 위조 프레임 (정상 AP 명의)
    Note over U: 정상 AP 연결 끊김
    U->>E: 같은 SSID, 신호 더 강한 쪽에 재접속
    E->>U: 가짜 로그인 페이지
    U->>E: ID/PW 입력 - 탈취
    E->>R: 사용자 트래픽 중계(눈치채지 못하게)

대응: WPA3(최소 WPA2-AES), 기업은 802.1X/EAP(사용자별 인증, 서버 인증서 검증으로 Evil Twin 방지), PMF(802.11w)(관리 프레임 보호 → Deauth 위조 차단), WIPS(비인가 AP·Evil Twin 탐지), 공용 Wi-Fi에서는 VPN 사용. SSID 숨김·MAC 필터링은 쉽게 우회되는 보조 수단.

6-4. 네트워크 진단 도구 ★ (실기)

traceroute 결과 읽기

$ traceroute -n 203.0.113.80
 1  192.168.0.1      0.512 ms  0.488 ms  0.471 ms
 2  10.10.0.1        3.102 ms  3.015 ms  2.998 ms
 3  * * *                                  ← 해당 라우터가 ICMP 응답을 막음(필터링)
 4  203.0.113.1     12.870 ms 12.811 ms 12.790 ms
 5  203.0.113.80    13.004 ms 12.955 ms 12.931 ms

• 첫 홉이 평소 게이트웨이(192.168.0.1)가 아니라 같은 LAN의 다른 IP라면 ARP 스푸핑·ICMP 리다이렉트를 의심.

tcpdump 핵심

tcpdump -nn -i eth0 host 203.0.113.9                   # 특정 호스트
tcpdump -nn -i eth0 'tcp port 80 and src net 10.0.0.0/8'
tcpdump -nn -i eth0 'tcp[13] == 2'                     # SYN만 (플래그 바이트 = 0x02)
tcpdump -nn -i eth0 'tcp[13] == 0x29'                  # XMAS (FIN+PSH+URG)
tcpdump -nn -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-fin) == (tcp-syn|tcp-fin)'   # SYN+FIN 비정상
tcpdump -nn -i eth0 icmp and 'icmp[0] == 8'            # ICMP Echo Request
tcpdump -nn -i eth0 arp                                # ARP만 (스푸핑 관찰)
tcpdump -nn -A -i eth0 'tcp port 21'                   # FTP 평문 계정 노출 확인

• tcp[13]: TCP 헤더의 13번째 바이트(0부터) = 플래그 바이트.

6-5. Wireshark와 로그 분석 ★ (실기)

캡처 필터 vs 디스플레이 필터

자주 쓰는 디스플레이 필터

• 분석 기능: Follow TCP Stream(세션 대화 재구성 → 평문 계정·명령 확인), Statistics > Conversations / Endpoints(누가 가장 많이 통신했나), Protocol Hierarchy, Export Objects > HTTP(전송된 파일 추출), Expert Information.

SSH 무차별 대입 로그 (/var/log/secure, 데비안 계열은 /var/log/auth.log)

Dec 22 03:14:07 web01 sshd[21877]: Failed password for root from 203.0.113.77 port 51122 ssh2
Dec 22 03:14:09 web01 sshd[21877]: Failed password for root from 203.0.113.77 port 51122 ssh2
Dec 22 03:14:12 web01 sshd[21881]: Failed password for invalid user admin from 203.0.113.77 port 51130 ssh2
Dec 22 03:14:15 web01 sshd[21885]: Failed password for invalid user oracle from 203.0.113.77 port 51134 ssh2
Dec 22 03:15:40 web01 sshd[21950]: Accepted password for test from 203.0.113.77 port 51188 ssh2

• 같은 IP에서 짧은 간격의 Failed password 반복, invalid user(존재하지 않는 계정) 대입 → 무차별 대입/사전 공격.
• 마지막 Accepted password for test → 공격 성공(취약한 test 계정). 즉시 계정 잠금, 해당 IP 차단, 침해 조사.

$ grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -3
   2841 203.0.113.77
     12 10.0.0.15
      3 10.0.0.22

• 대응: 비밀번호 정책, PermitRootLogin no, 키 인증, fail2ban, iptables recent(Day 5 ⑦).

방화벽(iptables LOG) 로그

Dec 22 14:02:11 fw01 kernel: SYN_FLOOD_DROP: IN=eth0 OUT= MAC=... SRC=45.33.12.7 DST=192.168.10.5 LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=54321 PROTO=TCP SPT=38012 DPT=80 WINDOW=512 RES=0x00 SYN URGP=0

• --log-prefix로 지정한 SYN_FLOOD_DROP:, 출발지·목적지, SYN 플래그, WINDOW=512 → Day 5 ⑤ 규칙이 SYN Flood를 잡아 버린 기록.

6-6. 악성코드·패킷 분석 도구

분석 순서(일반): 기초 정적 분석(해시·strings·패킹 확인) → 동적 분석(격리된 VM/샌드박스에서 실행·관찰) → 고급 정적 분석(디스어셈블) → 고급 동적 분석(디버깅). 분석 환경은 반드시 격리(스냅샷 VM, 내부망 분리).

6-7. SASE · ZTNA · XDR · EDR ★

제로 트러스트 (Zero Trust): "절대 신뢰하지 말고, 항상 검증하라(Never Trust, Always Verify)". 내부망이라는 이유만으로 신뢰하지 않는다. 모든 접근 요청마다 사용자·기기·위치·시간·행위를 검증하고 최소 권한만 준다. (NIST SP 800-207: 정책 결정 지점 PDP(PE·PA) / 정책 시행 지점 PEP)

ZTNA vs VPN

 [전통 VPN]                                  [ZTNA]
 사용자 ═══ VPN 터널 ═══▶ [VPN 게이트웨이]     사용자 ──▶ [ZTNA 브로커/정책 엔진]
                            │                            │ ① 사용자·기기 상태·상황 검증
           ┌────────────────┼─────────────┐              │ ② 허가된 앱 "A"에만 연결
           ▼                ▼             ▼              ▼
         앱 A             앱 B          DB 서버          앱 A   (앱 B, DB는 사용자에게 보이지도 않음)
   한 번 인증 → 내부 네트워크 전체 접근        매 세션 검증 → 애플리케이션 단위 최소 접근
   (침해 시 내부 횡적 이동 쉬움)               (공격 표면 최소화, 횡적 이동 차단)

6-8. (실기) 클라우드 네트워크 보안 — VPC · Security Group · NACL

 ┌──────────────────────── VPC 10.0.0.0/16 ─────────────────────────┐
 │                                                                  │
 │  ┌── 퍼블릭 서브넷 10.0.1.0/24 ──┐   ┌── 프라이빗 서브넷 10.0.2.0/24 ─┐ │
 │  │  [NACL-A]                     │   │  [NACL-B]                     │ │
 │  │   웹 서버 ⟨SG-Web⟩             │──▶│   DB 서버 ⟨SG-DB⟩              │ │
 │  │   NAT 게이트웨이               │   │   (인터넷 직접 접근 불가)        │ │
 │  └──────────────┬────────────────┘   └───────────────────────────────┘ │
 │           [인터넷 게이트웨이]                                         │
 └──────────────────┼───────────────────────────────────────────────┘
                 인터넷

• VPC (Virtual Private Cloud): 클라우드 안에 논리적으로 격리된 사용자 전용 네트워크. CIDR 대역 지정, 서브넷·라우팅 테이블·게이트웨이 구성.
• 퍼블릭 서브넷: 라우팅 테이블에 인터넷 게이트웨이(IGW) 경로가 있음. 프라이빗 서브넷: IGW 경로 없음, 외부로 나갈 때만 NAT 게이트웨이 사용.

Security Group 예 (SG-DB)

NACL 예 (NACL-A, 퍼블릭 서브넷)

• NACL은 Stateless라 HTTPS 요청(443 인바운드)을 허용해도 응답(서버 443 → 클라이언트 임시 포트) 이 아웃바운드에서 허용되지 않으면 통신 실패 → 임시 포트(Ephemeral Port) 1024-65535 규칙 필요.
• 특정 IP 차단은 Security Group으로 불가(허용만 있음) → NACL의 DENY로.
• 추가 보안 요소: VPC Flow Logs(트래픽 로그 → 분석), WAF, 클라우드 보안 형상 관리(CSPM).

⚠️ 시험 함정 (Day 6)

• SDN은 제어부(Control Plane)와 데이터부(Data Plane)를 분리. Northbound = 앱↔컨트롤러, Southbound = 컨트롤러↔스위치(OpenFlow). 방향을 바꿔 출제 가능.
• SMB 현재 포트는 TCP 445, NetBIOS는 137/138(UDP), 139(TCP). NetBEUI는 라우팅 불가.
• WannaCry가 이용한 것은 SMBv1(MS17-010, EternalBlue).
• WEP 무결성은 CRC-32(암호학적 해시 아님), IV 24비트. WPA2 = AES-CCMP, WPA = TKIP, WPA3 = SAE.
• traceroute는 TTL + ICMP Time Exceeded(11). 리눅스는 UDP, 윈도우 tracert는 ICMP.
• Wireshark 캡처 필터는 BPF 문법(host, port), 디스플레이 필터는 ==, && 문법. 섞어 쓰면 오류.
• Security Group = Stateful·허용만·인스턴스, NACL = Stateless·허용/거부·서브넷·번호 순서. 하나라도 바꿔 말하면 오답.
• ZTNA는 애플리케이션 단위 접근, VPN은 네트워크 단위. SASE는 네트워크(SD-WAN) + 보안을 클라우드로 통합(보안만이면 SSE).
• EDR = 엔드포인트, XDR = 여러 계층 통합. "XDR은 엔드포인트만 대상"은 오답.
• PEiD는 패킹 탐지, Regshot은 레지스트리 비교, Volatility는 메모리 분석.

📌 예상 출제 포인트 (Day 6)

• SDN 3계층 구조와 API 방향, 컨트롤러가 핵심 공격 대상인 이유.
• SMB/NetBIOS 포트와 취약점(EternalBlue), Null Session 대응.
• 무선 보안 규격별 암호·무결성 방식, Evil Twin·Deauth 대응(WPA3·PMF·WIPS·802.1X).
• 진단 도구 명령과 출력 해석(traceroute의 * * *, netstat 상태값).
• 제로 트러스트 원칙, ZTNA vs VPN, SASE 구성요소, EDR/XDR 정의.
• 실기: Security Group/NACL 규칙 설계 및 차이 서술, 로그를 보고 공격 판단 + 근거 + 대응.

✏️ 확인 문제 (Day 6)

Q1. SDN 구조에서 컨트롤러와 네트워크 스위치 사이의 통신에 사용되는 대표 프로토콜과 인터페이스 명칭이 바르게 짝지어진 것은?
① REST API – Northbound ② OpenFlow – Southbound ③ OpenFlow – Northbound ④ SNMP – Eastbound

Q2. 2017년 WannaCry 랜섬웨어의 자동 전파에 악용된 취약점과 관련 포트로 옳은 것은?
① SMBv1 EternalBlue – TCP 445 ② Heartbleed – TCP 443 ③ SMBGhost – UDP 137 ④ NTP monlist – UDP 123

Q3. WEP의 취약점에 대한 설명으로 옳지 않은 것은?
① 24비트 IV가 평문으로 전송되고 재사용된다. ② 무결성 검사에 CRC-32를 사용한다. ③ AES-CCMP를 사용하여 키 복구가 어렵다. ④ RC4 스트림 암호를 사용한다.

Q4. 클라우드 VPC의 Security Group과 Network ACL에 대한 설명으로 옳은 것은?
① Security Group은 서브넷 단위로 적용되며 거부 규칙을 지원한다.
② Network ACL은 상태 기반(Stateful)이므로 응답 트래픽 규칙이 필요 없다.
③ Security Group은 상태 기반으로, 허용된 인바운드 요청의 응답은 자동으로 허용된다.
④ Network ACL은 모든 규칙을 평가하여 하나라도 허용이면 허용한다.

Q5. 다음 설명에 가장 적합한 것은?
"사용자가 VPN으로 내부망 전체에 접속하는 대신, 매 요청마다 사용자 신원과 단말 상태를 검증하여 허가된 특정 애플리케이션에만 연결해 준다."
① SASE ② ZTNA ③ EDR ④ NAC

Day 7 · 주간 정리

주간 구조 요약

공격 → 원리 → 탐지 → 대응 한 장 정리

보안 기술 핵심어

미니 모의고사 (20문항, 원문 창작)

M1. SYN Flooding 공격을 받는 리눅스 서버에서 netstat -an으로 확인했을 때 비정상적으로 많이 나타나는 상태는?
① TIME_WAIT ② SYN_RECV ③ CLOSE_WAIT ④ FIN_WAIT2

M2. Fraggle 공격에 이용되는 프로토콜과 포트로 옳은 것은?
① ICMP Echo ② TCP 80 ③ UDP 7, 19 ④ UDP 53

M3. 다음 중 애플리케이션 계층 DoS 공격이 아닌 것은?
① Slowloris ② RUDY ③ CC Attack ④ Teardrop

M4. NTP 서버를 반사체로 이용한 증폭 공격을 막기 위해 서버 측에서 해야 할 조치는?
① SYN Cookie 활성화 ② monlist 기능 비활성화 ③ HSTS 설정 ④ 정적 ARP 등록

M5. 포트 스캔 결과 대상이 "SYN+ACK"로 응답했고, 스캐너가 곧바로 RST를 보냈다. 이 스캔과 포트 상태는?
① Connect 스캔 – 닫힘 ② SYN 스캔 – 열림 ③ ACK 스캔 – 필터링 ④ FIN 스캔 – 열림

M6. UDP 스캔에서 닫힌 포트를 판단하는 근거는?
① TCP RST 수신 ② ICMP Echo Reply 수신 ③ ICMP Destination Unreachable(Port Unreachable) 수신 ④ 무응답

M7. 좀비 호스트의 IP ID 증가량을 관찰하여 스캐너의 실제 IP를 대상에게 노출하지 않는 스캔은?
① Decoy 스캔 ② Idle 스캔 ③ XMAS 스캔 ④ Firewalking

M8. 스위치 환경에서 스니핑을 가능하게 하는 공격이 아닌 것은?
① 스위치 재밍 ② ARP 리다이렉트 ③ ICMP 리다이렉트 ④ SYN Flooding

M9. ARP 스푸핑의 근본 원인으로 가장 적절한 것은?
① ARP는 TCP 위에서 동작한다. ② ARP는 요청하지 않은 응답도 인증 없이 캐시에 반영한다. ③ ARP는 암호화를 기본 제공한다. ④ ARP는 라우터를 넘어 전달된다.

M10. DNS 응답에 전자서명을 추가하여 응답의 출처와 무결성을 검증하는 기술은?
① DoH ② DNSSEC ③ DNS RRL ④ Split DNS

M11. 세션 하이재킹이 진행될 때 탐지 단서가 되는 현상은?
① 브로드캐스트 스톰 ② ACK Storm ③ ARP 테이블 초기화 ④ TTL 증가

M12. 방화벽 유형 중 OSI 5계층에서 동작하며 SOCKS가 대표적인 것은?
① 패킷 필터링 ② 애플리케이션 게이트웨이 ③ 서킷 게이트웨이 ④ 상태 기반 검사

M13. 오용 탐지(Misuse Detection) IDS의 특징으로 옳은 것은?
① 제로데이 공격 탐지에 강하다. ② 정상 행위 학습 기간이 필요하다. ③ 오탐률이 낮지만 시그니처에 없는 공격은 탐지하지 못한다. ④ 통계적 분석 기법을 주로 사용한다.

M14. IDS의 처리 단계를 순서대로 나열한 것은?
① 정보 수집 → 분석 및 탐지 → 정보 가공 및 축약 → 보고 및 대응
② 정보 수집 → 정보 가공 및 축약 → 분석 및 탐지 → 보고 및 대응
③ 정보 가공 및 축약 → 정보 수집 → 분석 및 탐지 → 보고 및 대응
④ 분석 및 탐지 → 정보 수집 → 정보 가공 및 축약 → 보고 및 대응

M15. 여러 보안 장비와 서버의 로그를 수집하고 상관 분석하여 위협을 탐지하며, 장기 보관 기능을 갖춘 시스템은?
① UTM ② SIEM ③ NAC ④ WAF

M16. TLS 1.2에서 "이후부터 협상된 암호 방식을 적용한다"는 신호를 전달하는 프로토콜은?
① Alert ② Record ③ ChangeCipherSpec ④ Heartbeat

M17. 사용자가 처음 HTTP로 접속하는 순간을 노려 HTTPS 연결을 HTTP로 바꿔치기하는 공격과 대응이 바르게 연결된 것은?
① POODLE – SSL 3.0 비활성화 ② SSL Stripping – HSTS ③ Heartbleed – 인증서 재발급 ④ BEAST – TLS 압축 비활성화

M18. IPSec에서 NAT 장비를 통과시키기 위해 ESP 패킷을 UDP로 캡슐화할 때 사용하는 포트는?
① UDP 500 ② UDP 1701 ③ UDP 4500 ④ TCP 1723

M19. 다음 Snort 룰 옵션 중 "페이로드 처음부터 몇 바이트 안에서만 content를 검색할지"를 지정하는 것은?
① offset ② depth ③ distance ④ within

M20. iptables에서 패킷을 차단하면서 송신자에게 거부 응답을 보내는 타깃은?
① ACCEPT ② DROP ③ REJECT ④ RETURN

카드

• SYN Flooding 대응 핵심 : SYN Cookie
• SYN Flooding 시 서버 TCP 상태 : SYN_RECV (half-open)
• SYN Cookie가 연결 정보를 넣는 곳 : SYN+ACK의 초기 순서번호(ISN)
• Smurf 3요소 : ICMP + 브로드캐스트 + 출발지 위조
• Smurf 증폭 네트워크 라우터 설정 : no ip directed-broadcast
• Smurf의 UDP 버전 : Fraggle (echo 7, chargen 19)
• 출발지 = 목적지 : Land
• 단편 오프셋 조작 : Teardrop
• 단편 순서번호를 모두 같게 : Bonk
• 65,535 초과 ICMP : Ping of Death
• 헤더 끝을 안 보내는 공격 : Slowloris
• Content-Length 크게, 바디 느리게 : RUDY (Slow POST)
• TCP 윈도우를 작게 해 응답을 느리게 읽음 : Slow Read
• Cache-Control: no-cache로 캐시 우회 : CC Attack
• 반사·증폭 DDoS : DRDoS
• 증폭률이 가장 큰 반사 서비스 : Memcached (UDP 11211)
• NTP 증폭 명령 : monlist
• 암호화 통신하는 DDoS 도구 : TFN2K, Stacheldraht
• 트래픽을 우회시켜 정제 후 정상만 전달 : 클린존 (사이버대피소)
• 출발지 경로를 역조회해 위조 패킷 폐기 : uRPF
• 출발지 위조 방지 필터링 표준 : BCP38 (RFC 2827, Ingress 필터링)
• 로그 덜 남는 스캔 : SYN 스캔 (Half-open)
• XMAS 플래그 : FIN, PSH, URG
• FIN 스캔 열린 포트 응답 : 없음
• FIN/NULL/XMAS가 안 통하는 OS : Windows
• UDP 스캔 닫힌 포트 응답 : ICMP Port Unreachable
• 방화벽 필터링 확인 스캔 : ACK 스캔
• 좀비 IPID 이용 스캔 : Idle 스캔
• TTL로 방화벽 통과 포트 확인 : Firewalking
• 수동 OS 핑거프린팅 도구 : p0f
• TTL 128이면 추정 OS : Windows
• 웹 서버 취약점 스캐너 : Nikto
• 오픈소스 종합 취약점 스캐너 : OpenVAS
• ARP 스푸핑 대응 : 정적 ARP (arp -s), DAI
• DAI가 참조하는 테이블 : DHCP Snooping 바인딩 테이블
• MAC 테이블 넘치게 : 스위치 재밍 → 포트 보안
• ICMP Redirect 타입 번호 : 5
• 무차별 모드 : Promiscuous
• 가짜 MAC으로 의심 IP에 ping : 스니퍼 탐지 (Ping 방법)
• 가짜 IP 뿌리고 역질의 감시 : 스니퍼 탐지 (DNS 방법)
• DNS 위조 근본 대응 : DNSSEC
• 세션 하이재킹 징후 : ACK Storm
• 방화벽 우회하는 아웃바운드 셸 : 리버스 쉘 → Egress 필터링
• 세션 상태 테이블 방화벽 : Stateful Inspection
• 5계층 방화벽, SOCKS : 서킷 게이트웨이
• DMZ 가진 방화벽 구성 : 스크린드 서브넷
• 외부에 노출된 강화 호스트 : 배스천 호스트
• 방화벽 규칙 처리 방식 : 위에서부터 첫 일치 + 묵시적 거부
• 신종 공격 탐지 IDS : 이상 탐지
• 더 위험한 오류 : False Negative (미탐)
• IDS 처리 순서 : 수집 → 가공·축약 → 분석·탐지 → 보고·대응
• 인라인 차단 : IPS
• IPS 장애 시 통과시키는 설정 : Fail-Open
• 이벤트 통합 + 상관분석 : SIEM
• 플레이북 기반 대응 자동화 : SOAR
• 여러 보안 기능을 한 장비에 : UTM
• 단말 보안 상태 검사 후 접속 : NAC
• 정보 유출 방지 : DLP
• 확률적 패킷 마킹 : PPM (IP 패킷 역추적)
• TLS 하위 프로토콜 4개 : Handshake, ChangeCipherSpec, Alert, Record
• TLS Record 순서 : 단편화 → 압축 → MAC → 암호화
• TLS 1.3 핸드셰이크 RTT : 1-RTT (재연결 0-RTT)
• TLS 1.3 키 교환 : (EC)DHE만 (PFS)
• OpenSSL Heartbeat 메모리 노출 : Heartbleed
• SSL 3.0 패딩 오라클 : POODLE
• HTTPS 다운그레이드 대응 : HSTS
• IPSec 암호화 없는 것 : AH (51)
• ESP 프로토콜 번호 : 50
• IPSec 키 교환 : IKE (UDP 500)
• IPSec NAT 통과 : NAT-T (UDP 4500)
• SA 식별 3요소 : SPI + 목적지 IP + 보안 프로토콜
• 패킷 전체 보호 모드 : 터널 모드
• L2TP 포트 / PPTP 포트 : UDP 1701 / TCP 1723 + GRE
• 브라우저만으로 접속하는 VPN : SSL VPN
• Snort 사용자 정의 sid 범위 : 1,000,000 이상
• Snort 출발지=목적지 탐지 옵션 : sameip
• iptables 응답 패킷 허용 : -m state --state ESTABLISHED,RELATED
• iptables 응답 없이 폐기 : DROP
• SDN 컨트롤러-스위치 프로토콜 : OpenFlow (Southbound)
• WannaCry 취약점 : SMBv1 EternalBlue (MS17-010, TCP 445)
• WEP 무결성 방식 : CRC-32
• WPA3 인증 : SAE
• 같은 SSID 가짜 AP : Evil Twin
• 앱 단위 최소 접근 : ZTNA
• SD-WAN + 보안을 클라우드로 : SASE
• 다계층 통합 탐지·대응 : XDR
• Stateful·허용만·인스턴스 단위 : Security Group
• Stateless·허용/거부·서브넷 단위 : NACL
• 레지스트리 전후 비교 도구 : Regshot
• 메모리 포렌식 도구 : Volatility

오답 노트

네비게이션